Solving Backend Coupling Issues with a Dedicated TPS Microservice

Coupling Problem

Sometimes when calling interfaces, such as a push notification interface, multiple channels need to be handled.

In my current business scenario, the settlement backend interacts with the Kingdee financial system. The settlement backend deals with several settlement order types, and exposing a separate controller for each type leads to many controllers, many of which share common third‑party interfaces.

Issues on the Frontend

Multiple controllers must be called with different parameters; any change in a backend interface requires modifications on many pages, resulting in high coupling.

Permission configuration is needed for many buttons.

Issues on the Backend

Each business interface needs its own method to push to the third‑party service, creating a lot of duplicated code and high coupling.

When a third‑party service interface changes, many backend interfaces must be updated.

Solution

Create a dedicated microservice (named TPS) that only handles communication with third‑party services, encapsulating common parameters.

Other business systems (order, settlement, supplier) call this TPS service via a unified Feign interface; they implement the Feign client provided by TPS.

Business systems focus on service‑layer logic and do not need to handle third‑party integration details.

The overall flow diagram is shown below:

Specific Implementation

TPS Service

The TPS service exposes a Feign interface that the frontend calls uniformly.

//对接第三方服务接口
public
interface
IKingdeeManagementService
{
Boolean
push
(KingdeePushCO.Request request)
;
}

Feign interface implementation class:

@Slf
4j
@Service
public
class
KingdeeManagementServiceImpl
implements
IKingdeeManagementService
{
@Autowired
private
ApplicationContext applicationContext;
@Autowired
private
KingdeeThirdSettingService kingdeeThirdSettingService;
@Override
public
Boolean
push
(KingdeePushCO.Request request)
{
KingdeeBusinessPushServiceEnum kingdeePushServiceEnum = KingdeeBusinessPushServiceEnum.getKingdeePushServiceEnumByType(request.getBusinessType());
IKingdeeBusinessPushService kingdeePushService =
null
;
try
{
kingdeePushService = (IKingdeeBusinessPushService) applicationContext.getBean(kingdeePushServiceEnum.getClazz());
}
catch
(BeansException e) {
log.error(
"当前类型暂未实现,请联系开发"
);
throw
new
ServiceException(
"当前类型暂未实现,请联系开发"
);
}
R<Boolean> result =
null
;
result = kingdeePushService.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;
}
RECEIPT_VOUCHER(IJaKingdeeBillClient
.
class
,
KingdeeBusinessTypeConstant
.
RECEIPT_VOUCHER
,
KingdeeSettingEnum
.
INTERFACE_TYPE_JA_RECEIPT_VOUCHER
.
getCode
()),
;
}

The enum contains three attributes:

clazz – defines the Feign interface that the business system provides.

type – the integer value the frontend passes; different values map to different Feign interfaces.

interFaceName – the name of the third‑party interface to be invoked.

Business System

Using the BMS service as an example, it inherits the TPS Feign interface and overrides the push method.

The Feign implementation is initialized via a factory class, allowing different service implementations.

The utility JaKingdeeFactoryUtil obtains factory instances; an enum mapping could also be used to avoid many case statements.

JaKingdeeServiceFactory is an interface that provides methods; its implementation follows a double‑checked locking singleton pattern with pessimistic locking to prevent multiple creations. SpringContextUtils.getBean retrieves service instances, and the business layer only needs to implement the service interface for different push logics.

Conclusion

This design presents a unified approach for invoking third‑party interfaces, addressing repeated calls, result caching, timeout handling, and fallback strategies; readers are invited to share alternative solutions.