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.
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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.