Domain-Driven Design (DDD) and Microservice Architecture: Concepts, Patterns, and Refactoring Strategies

Domain-Driven Design (DDD) and microservice architecture are widely used methods to improve system responsiveness by separating complexity from a business perspective.

This article introduces the basic concepts, terminology, architectural patterns of DDD and how to refactor an existing system.

What is DDD? DDD is an architectural design approach that emphasizes defining domain boundaries based on business, adjusting existing architecture, and optimizing code for evolutionary architecture. Its core idea is to split domains to manage business complexity.

Domain Definition A domain limits the business scope. A domain model abstracts entities, value objects, aggregates, factories, and repositories, created jointly by domain experts and developers. Example: the transaction domain covers all transaction‑related business.

Bounded Context Defines boundaries within which a unified language and rules are used. Different bounded contexts can use the same terms with different meanings, enabling independent logic and data models.

Integration Methods

Event‑Driven: one context publishes events, another subscribes.

Request‑Response: contexts communicate via request and response.

Shared Database: multiple contexts share the same database.

REST API: contexts interact through RESTful calls.

Architecture Evolution Software architecture evolves from monolithic to distributed microservices, each stage aiming to improve responsiveness by separating complexity.

Architecture Patterns

Layered Architecture : interface, application, domain, anti‑corruption, infrastructure layers.

CQRS : separates command (write) and query (read) models.

Event‑Driven Architecture (EDA) : uses events for loose coupling and high concurrency.

Microservice Architecture : services are independently deployable, support multiple tech stacks, and improve scalability.

Refactoring Vision The current transaction system has high coupling between payment and order domains, leading to unclear responsibilities, poor maintainability, and limited extensibility.

Refactoring Goals

Isolate core transaction business by splitting and migrating existing logic.

Improve maintainability by using DDD to split sub‑domains.

Enhance extensibility with design patterns and extension points.

Domain Partitioning Consider business clarity, collaboration with domain experts, avoid over‑partitioning, flexibility for business changes, and aggregation relationships.

Steps Example

Identify business domains through interviews and use‑case analysis.

Define domain models (entities, value objects, aggregates, factories, repositories).

Determine bounded contexts and their responsibilities.

Design interaction patterns (event‑driven, request‑response, etc.) for context communication.

Core Domains

Payment Center: handles player payments and channel management.

Order Center: manages order lifecycle and transaction processing.

General Domains

Product Domain: manages game product information.

Discount Domain: handles coupons and points deductions.

Supporting Domains

CP Domain: interacts with game development.

Marketing Domain: maintains high‑value players and revenue.

The article concludes that DDD, while not a silver bullet, helps to rationally split systems from a business perspective, identify architectural issues, and improve code structure.

References to open‑source DDD frameworks and further reading are provided.