Applying Domain-Driven Design to Payment Systems: A Comprehensive Guide

In Airwallex, Domain-Driven Design (DDD) is used to model a complex payment system, covering order processing, fraud detection, notifications, multiple payment methods, fund clearing and settlement.

The article outlines common problems such as unclear boundaries, lack of modularity, and mixed concerns, and explains how DDD’s strategic and tactical patterns address them.

Strategic design defines the problem space with bounded contexts and a ubiquitous language, while the solution space applies tactical patterns like entities, aggregates, domain events, services, and repositories to build loosely‑coupled, cohesive microservices.

A concrete scenario—purchasing a T‑shirt for $10—is used to demonstrate the steps: analyzing use cases, defining bounded contexts, applying tactical DDD patterns, and mapping contexts to microservices.

The analysis identifies the payment domain, sub‑domains (payment processing and finance), and defines ubiquitous terms such as payment intent, payment attempt, payment method, settlement, and payment view.

Bounded contexts such as Payment Gateway, Payment Core, Payment Adapter, Payment Settlement, and Payment Fusion are described, along with their domain models, services, events, and infrastructure implementations (e.g., PostgreSQL repositories).

Domain services are stateless business‑logic components that encapsulate repositories, aggregate changes, and event publishing; an example is the PaymentAttemptExecutorService.

Domain events decouple core processes from side effects, enabling scalability; for instance, PaymentCaptureCommand triggers a PaymentAttemptCapturedEvent to update related bounded contexts.

The infrastructure layer separates technical details from the domain model, often using an anti‑corruption layer; examples include PostgreSQL‑based repositories for persisting aggregates.

Mapping bounded contexts to microservices yields candidate services for each context, illustrated by a context‑to‑service diagram.

Conclusion: DDD provides a mature set of patterns for managing complexity in payment systems, enabling better extensibility, clearer code, and easier evolution of microservice architectures.