Practical Application of Domain‑Driven Design (DDD) in an Internal Trading Center Microservice

Introduction: The author shares two years of experience applying Domain‑Driven Design (DDD) to payment, settlement, and fund services, and presents practical insights from a recent microservice called Internal Trading Center.

DDD Overview: DDD consists of strategic design (domain modeling) and tactical design (implementation). Strategic modeling belongs to the strategic layer, while engineering implementation belongs to the tactical layer; they can be combined as needed.

Architecture Layer Theories:

Classic DDD Four‑Layer Architecture

Clean Architecture

Hexagonal Architecture

Diamond Architecture

CQRS (Command Query Responsibility Segregation)

Combined Architecture Design: Based on the company’s situation, the author integrates the strengths of the above architectures into a customized stack: classic DDD four‑layer skeleton, CQRS for command/query separation, Clean Architecture to separate technical code from domain code, and Diamond Architecture to organize north‑bound and south‑bound gateways.

Code Structure Example: Using Maven, the project is split into api and service modules. The api module defines contracts (enums, DTOs, interfaces) and is depended on by all service layers. The service module implements the DDD four layers (access, application, domain, infrastructure) and may be further divided into separate modules to enforce dependency rules.

Layer Details:

Access Layer (api): thin façade handling HTTP/Feign requests, data conversion, and contract validation.

Application Layer: orchestrates business processes, handles cross‑aggregate logic, hosts events, and may call domain services directly.

Domain Layer: core business model, aggregates, repository interfaces, factories, and domain services; external APIs are abstracted as ports.

Infrastructure Layer: technical concerns, repository implementations, DAO/PO classes, configuration, and utility code.

Key Takeaways: Identify business boundaries, keep business and technical code decoupled, use interfaces to isolate changes, and apply appropriate design patterns (factory, strategy, observer, chain of responsibility) within the proper layer.

Practical Guidance: Follow the three steps of DDD domain modeling (boundary, ubiquitous language, model organization) and the four steps of DDD engineering (integrate frameworks, define division, map models to code, classify special code).

Promotional Note: The author invites readers to like, share, and subscribe, and promotes a knowledge‑sharing platform offering additional DDD, Spring, and big‑data content for a fee.