How to Build a Scalable B2B Payment System with SPI and Composition

Introduction

In B2B systems, high concurrency is less of a challenge, but a single process often needs to support many differentiated business requirements, making extensibility the biggest challenge. Using the copyright‑asset‑management finance system as an example, the article explains how to use one workflow to serve all business lines.

Problems with Template Pattern

Initially the system used the Template pattern with inheritance to handle variations. As the number of business lines grew, inheritance became “fat” or “tall”, leading to code duplication, poor reuse, and risk of changes propagating unintentionally.

The design principle “prefer composition over inheritance” is advocated to achieve looser coupling.

Building an Extension Framework

Four steps were taken:

Identify workflow differences.

Model the domain.

Create a secondary abstraction layer.

Construct an SPI‑based extension mechanism.

Domain Modeling

The payment document is the aggregate root; each business line can initiate a payment, making other domains supporting domains. Directly referencing other domain documents makes the core domain unstable, so an isolation layer is introduced.

Secondary Abstraction Layer

A “payment voucher” is extracted as an intermediate abstraction. The core payment flow depends only on the voucher, while translators in business domains convert their own documents to vouchers, keeping the core stable.

SPI Extension System

Interfaces are defined in the payment domain and implemented by business domains. Various SPI implementations (Java SPI, Spring‑SPI, Dubbo‑SPI, TMF‑SPI, COLA‑SPI) were evaluated; COLA‑SPI was chosen for its automatic business‑identity mapping and simplicity.

Security and Isolation

Extension packages are loaded via Maven as release versions, ensuring business‑identity safety. Data, MQ, interface, environment, and logical isolation are enforced through interceptors, topic segregation, and strict release‑only deployment.

Conclusion

By following the four steps, the architecture gains extensibility, avoids the pitfalls of the template pattern, and delegates business‑specific logic to extensions, improving maintainability and scalability of the B2B system.