Backend Development 8 min read

Decoupling Backend Interfaces with a Dedicated TPS Microservice

The article analyzes coupling problems caused by multiple backend controllers and third‑party push interfaces, proposes a dedicated TPS microservice to encapsulate third‑party calls, demonstrates Feign integration with Java code examples, and concludes with a summary of benefits and further considerations.

Top Architect
Top Architect
Top Architect
Decoupling Backend Interfaces with a Dedicated TPS Microservice

In this article, the author, a senior architect, discusses the coupling issues that arise when multiple backend controllers expose separate endpoints for different settlement types and third‑party push services, leading to high maintenance overhead for both frontend and backend teams.

1. Coupling Problems

When a push interface needs to interact with various channels, each settlement type may require its own controller, causing duplicated code and high coupling. Frontend developers must adjust many pages when backend APIs change, and backend developers must write repetitive push methods for each third‑party service.

Frontend Issues

Multiple controllers with different parameters increase page modifications when APIs change.

Permission configuration for many buttons becomes cumbersome.

Backend Issues

Each business interface implements its own third‑party push method, leading to duplicated code.

Changes to third‑party services require extensive modifications across many backend interfaces.

2. Solution

Create a dedicated microservice (named tps ) that handles all third‑party integrations, encapsulating common parameters.

Other business services (order, settlement, supplier) call the tps service via Feign interfaces, delegating the actual push logic.

Business services focus only on their own service‑layer logic without dealing with third‑party details.

The overall flow is illustrated with a diagram (omitted here).

3. Implementation Details

Tps Service Interface

// Interface for third‑party service integration
public interface IKingdeeManagementService {
    Boolean push(KingdeePushCO.Request request);
}

Feign Implementation

@Slf4j
@Service
public class KingdeeManagementServiceImpl implements IKingdeeManagementService {
    @Autowired
    private ApplicationContext applicationContext;
    @Autowired
    private KingdeeThirdSettingService kingdeeThirdSettingService;

    @Override
    public Boolean push(KingdeePushCO.Request request) {
        KingdeeBusinessPushServiceEnum enumVal = KingdeeBusinessPushServiceEnum.getKingdeePushServiceEnumByType(request.getBusinessType());
        IKingdeeBusinessPushService service = null;
        try {
            service = (IKingdeeBusinessPushService) applicationContext.getBean(enumVal.getClazz());
        } catch (BeansException e) {
            log.error("Current type not implemented, contact developer");
            throw new ServiceException("Current type not implemented, contact developer");
        }
        R
result = service.pushKingdee(request);
        return true;
    }
}

Enum Definition

public enum KingdeeBusinessPushServiceEnum {
    private Class clazz;
    private Integer type;
    private String interFaceName;
    KingdeeBusinessPushServiceEnum(Class clazz, Integer type, String interFaceName) {
        this.clazz = clazz;
        this.type = type;
        this.interFaceName = interFaceName;
    }
    // Example entry
    RECEIPT_VOUCHER(IJaKingdeeBillClient.class, KingdeeBusinessTypeConstant.RECEIPT_VOUCHER, KingdeeSettingEnum.INTERFACE_TYPE_JA_RECEIPT_VOUCHER.getCode()),
}

The enum maps each business type to a Feign interface, a type identifier, and a descriptive name, allowing the factory to retrieve the appropriate implementation.

Factory and Service Usage

Business systems obtain the tps Feign client via a factory (e.g., JaKingdeeFactoryUtil ) which uses double‑checked locking to ensure a singleton instance. This abstracts the third‑party push logic away from individual services.

4. Summary

The proposed architecture centralizes third‑party push calls in a dedicated microservice, reducing code duplication, lowering coupling, and simplifying maintenance. It also opens the door for caching, timeout handling, and fallback strategies, providing a cleaner and more scalable solution for interface integration.

Additionally, the article includes promotional content for a ChatGPT community, offering free accounts, courses, and other benefits, but the core technical discussion remains focused on backend decoupling and microservice design.

BackendJavaarchitecturefeignMicroservicecoupling
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.