Understanding Domain-Driven Design (DDD) for Microservices and Platform Architecture

1. Overview

DDD stands for Domain-Driven Design, a methodology commonly used in microservice systems to define domain models, determine business and application boundaries, and ensure consistency between business and code models.

Platform (Mid‑Platform)

The concept of a mid‑platform, introduced in 2015, aims to consolidate reusable business capabilities into a shared business model for enterprise‑level reuse, which leads to the need for restructuring the platform domain model.

Encapsulate reusable business capabilities into the platform business model to achieve enterprise‑wide reuse.

The platform faces three core concerns: microservices, the platform itself, and DDD for domain modeling.

2. What is DDD?

DDD’s core idea is to define domain models through domain‑driven design, establishing business boundaries and ensuring alignment between business models and code.

It separates technical complexity from business concepts, building a domain model around business concepts to control complexity and improve understandability and evolvability.

Strategic Design : From a business perspective, it creates a domain model, defines bounded contexts, and establishes a ubiquitous language that can guide microservice boundaries.

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

3. DDD Layered Architecture

The architecture consists of four layers:

User Interface Layer : UI, web services, and any client that interacts with the system.

Application Layer : Thin layer that orchestrates use‑cases, handles security, transactions, and composes services; it should contain no business rules.

Domain Layer : Core business logic, containing aggregates, entities, value objects, and domain services; implements the business model.

Infrastructure Layer : Provides technical services such as databases, messaging, object storage, and caching, abstracted behind interfaces.

4. Key Objects in DDD

Persistent Object (PO): Maps one‑to‑one with database structures for data persistence.

Domain Object (DO): Core business entity or value object used at runtime.

Data Transfer Object (DTO): Carries data between front‑end and back‑end or between services.

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

Other objects (e.g., aggregates, repositories) follow the same mapping principles.

5. Domain Classification

Domains are divided into sub‑domains: core, generic, and supporting, each serving different business purposes.

6. Implementing DDD Process

Event storming – collaborative brainstorming with domain experts to build the model.

Analyze user stories (scenarios).

Define domain objects: entities, aggregates, value objects, events, services, repositories.

Map domain objects to code models.

Implement the code based on the model.

7. Bounded Context and Ubiquitous Language

A bounded context defines the domain boundary, encapsulating a ubiquitous language and domain objects, often aligning with a microservice boundary.

8. Entity

Entities have a unique identifier, mutable state, and are the primary carriers of business behavior.

Example (Java):

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 typically use the rich (active) model.

9. Value Object

Value objects are immutable, have no identity, and represent a set of attributes that describe a concept.

10. Aggregate and Aggregate Root

An aggregate groups tightly related entities and value objects; the aggregate root enforces invariants and provides a single entry point for external access.

11. Domain Events

Domain events capture significant occurrences within the domain, enabling decoupled reactions and eventual consistency across microservices.

References :

《实现领域驱动设计》

《领域驱动设计‑软件核心复杂性应对之道》

https://time.geekbang.org/column/intro/100037301?tab=catalog