Domain-Driven Design (DDD): A Comprehensive Guide for Microservices and Platform Architecture

Learning microservices and middle‑platform architecture inevitably leads to Domain-Driven Design (DDD). This article provides a thorough walkthrough.

1. Overview

DDD stands for Domain‑Driven Design, a design approach commonly used in microservice systems to address the contentious problem of service decomposition.

When discussing microservices, we inevitably talk about the middle‑platform ("中台"). The middle‑platform aims to consolidate reusable business capabilities into a shared business model for enterprise‑level reuse.

Put reusable business capabilities into a middle‑platform business model to achieve enterprise‑level reuse. 可复用

The primary issue for the middle‑platform is the reconstruction of its domain model, and it still faces microservice design and splitting challenges.

Microservices : The middle‑platform is supported by microservices.

Middle‑platform : Reuse business capabilities to achieve enterprise‑level reuse.

DDD : Perform domain modeling for the middle‑platform, creating a model suitable for enterprise growth.

DDD can be seen as the product manager for microservices and the middle‑platform, focusing on domain‑oriented business functions rather than database tables.

2. What is DDD?

The core idea of DDD is to define a domain model through domain‑driven design methods, establishing business and application boundaries and ensuring consistency between business and code models.

DDD tackles highly complex domains by separating technical complexity and building a domain model around business concepts, addressing problems of code understandability and evolution.

Strategic Design : From a business perspective, it creates a domain model, defines bounded contexts, and establishes a ubiquitous language, which can serve as a reference for microservice boundaries.

Tactical Design : From a technical perspective, it focuses on the technical implementation of the domain model, including aggregates, entities, value objects, domain services, application services, and repositories.

3. DDD Architectural Layers

The following diagram illustrates the layered architecture (image omitted for brevity).

User Interface Layer

Contains user interfaces and web services, responsible for displaying information and interpreting user commands.

Application Layer

Should contain no business logic; it is a thin layer that orchestrates use‑case and workflow‑related operations, exposing coarse‑grained services via an API gateway.

Domain Layer

Implements core business logic, similar to the Service layer in a traditional three‑tier architecture. It includes aggregates, entities, value objects, and domain services.

Infrastructure Layer

Provides common technical services such as databases, message middleware, object storage, and caching. Changing infrastructure components requires only minimal adjustments in this layer.

4. Objects in DDD

Persistent Object (PO) : Maps one‑to‑one with database structures and serves as the data carrier during persistence.

Domain Object (DO) : Core business object in microservices, usually an entity or value object.

Data Transfer Object (DTO) : Carries data between the front‑end and application layer or between microservices.

View Object (VO) : Encapsulates data for presentation layers.

Other objects such as PO, DO, DTO, VO are used across the infrastructure, domain, application, and user‑interface layers according to their responsibilities.

5. Domain Classification

DDD divides a business domain into sub‑domains: core domain (key competitive advantage), generic domain (shared across sub‑domains), and supporting domain (non‑core, non‑generic).

6. DDD Implementation Process

Step 1 : Event storming – domain experts collaborate with designers and developers to build the domain model.

Step 2 : Analyze user stories (scenarios) within the domain.

Step 3 : Define domain objects – design entities, identify aggregate roots, create value objects, domain events, domain services, and repositories.

Step 4 : Map domain objects to a code model that contains business logic.

Step 5 : Implement the code model.

7. Bounded Context and Ubiquitous Language

Bounded Context

A bounded context defines the domain boundary, encapsulating a ubiquitous language and domain objects, ensuring terms have precise meanings.

In theory, a bounded context corresponds to a microservice; one can design a microservice per bounded context.

Logical Boundary: The boundary between aggregates within a microservice.

Physical Boundary: The deployment and runtime isolation between microservices.

Code Boundary: Directory or package boundaries separating layers or aggregates.

Ubiquitous Language

All participants must use a consistent terminology within a bounded context, and the code model should reflect this language, aligning business and code models.

8. Entities

Entity Concept

Entities (DOs) have unique identifiers, mutable state, and encapsulate business behavior.

public class Product {
  // 商品实体
  private long id; // 商品唯一 id
  private String name; // 单一属性值对象
  private Location location; // 属性值对象，被实体引用
}

public class Location {
  // 值对象，无主键 id
  private String country;
  private String province;
  private String city;
  private String street;
}

Entities usually follow the rich (or “active”) model, containing both data and behavior.

Rich vs. Anemic Model

Anemic Model: Separates data and business logic into different classes (e.g., Model and Service).

Rich Model: Encapsulates data and business logic within the same entity class.

9. Value Objects

Concept

Value objects represent immutable concepts composed of several attributes; they have no identity and are compared by value.

Characteristics

No ID, immutable, no lifecycle, used to describe entity attributes.

10. Aggregates and Aggregate Roots

Aggregate

An aggregate groups closely related entities and value objects, serving as the unit of data modification and persistence.

Aggregate Root

The aggregate root controls access to the aggregate, ensuring consistency and providing a single entry point.

11. Domain Events

Domain events represent occurrences within the domain, enabling decoupled processing and eventual consistency across microservices.

References

"Implementing Domain‑Driven Design", "Domain‑Driven Design: Tackling Complexity in the Heart of Software", and various online articles.

Author: 悟空聊架构 (Wukong Architecture Talk)

Content is for learning and research only; all rights belong to the original author.