Designing a Retail Financial Middle Platform: From Business Architecture to Microservices

Background

In traditional retail operations, massive business data are generated and processed by finance staff for accounting and reporting, consuming large amounts of manual effort that could be automated. To reduce repetitive accounting work and free resources for higher‑value financial analysis, a financial middle platform is introduced as a bridge between business systems and the general ledger.

Financial Middle Platform Business Architecture

The retail business architecture is divided into three layers: front‑office (fast‑changing, multi‑channel experiences), headquarters middle platform (centralized services such as membership, transactions, marketing, operations, finance, and data), and enterprise/backend (procurement, supply chain, production, contracts, and accounting). The headquarters middle platform aggregates all business data, enabling unified verification, accounting, and financial management without switching between multiple systems.

Financial Middle Platform Business Architecture

The platform collects data from all channels, performs filtering, accounting, and transformation, automatically generates financial records, and feeds them into the general ledger. It also offers standardized open APIs for other systems, partner reconciliation services, and raw data for reporting and analysis.

Application Architecture Design

Application architecture defines the logical modules of a system and their relationships, serving as a bridge between business architecture and technology choices. The design follows Simon Brown’s C4 model, which consists of four layers: System Context, Containers, Components, and Classes.

System Context Layer

This top‑level view shows the financial middle platform and its interactions with external systems such as retail front‑office, supply‑chain, and the general ledger.

Container Layer

Containers correspond to bounded contexts in Domain‑Driven Design (DDD). Identifying bounded contexts is crucial for later micro‑service decomposition. The platform adopts a layered container architecture: Application Layer, Domain Layer, Infrastructure Layer, and an Anti‑Corruption Layer for external integration.

Component Layer

Within each container, components are logical groups of classes that fulfill specific responsibilities. Typical components include:

Interface Layer – defines APIs exposed to upper layers.

Application Layer – orchestrates domain services and business use‑cases, often deployed as a micro‑service.

Anti‑Corruption Layer – isolates internal models from external changes.

The Application Layer remains thin, delegating core business logic to the Domain Layer.

Class Layer

This lowest level details the concrete classes, their responsibilities, and relationships. It is omitted for brevity.

Microservice Architecture Design

Microservices split the system into small, autonomous services aligned with business domains. Benefits include independent deployment, scaling, and team ownership, while drawbacks involve distributed complexity, data consistency, and testing challenges. The article recommends:

Start with a few services; avoid over‑splitting before business complexity justifies it.

Use bounded‑context complexity and technical requirements (high concurrency, strict performance) to decide service boundaries.

Group tightly coupled contexts (e.g., settlement and invoice details) to avoid distributed transaction problems.

Examples illustrate how the accounting domain, with high transaction volume, is isolated as a dedicated micro‑service, while other contexts remain combined.

Middle Platform, DDD, and Microservices

The middle‑platform strategy (originating from Alibaba) abstracts common functionalities across business lines into reusable components. DDD provides the design methodology for modeling complex domains, and microservices act as the technical implementation mechanism that materializes the middle‑platform architecture.

Conclusion

The article presents a practical case study of Youzan’s retail financial middle platform, demonstrating how to derive an application architecture from the overall business structure, apply the C4 model to design system context, containers, components, and classes, and use bounded‑context analysis to guide micro‑service decomposition. The insights aim to help developers design robust, scalable architectures for complex retail systems.