DDD (Domain-Driven Design)

Software Engineering & Development Methodologies

Domain-Driven Design

1. Overview of DDD: A Methodology for Designing Complex Software Around the Business Domain

    flowchart LR
    A["Technology/DB-centered design<br/>(technical debt, distorted domain)"] --"Shift to a<br/>domain-model-centered approach"--> B["Ubiquitous Language<br/>+ Bounded Context"] --"Apply strategic<br/>& tactical design"--> C["Build a maintainable<br/>complex system"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: A methodology for solving complex business problems by placing the model and logic of the business domain — rather than the technical implementation — at the center of design, developing software based on a common language (Ubiquitous Language) shared between domain experts and developers.

Characteristics: (Ubiquitous Language) Domain experts and developers use the same terminology consistently in code, documentation, and conversation. (Strategic design) Bounded Contexts and Context Maps separate a complex domain into independent boundaries. (Tactical design) Aggregates, Entities, Value Objects, and Domain Events precisely implement the domain model.

2. Core Structure of DDD

a. Strategic Design — Bounded Context and Context Map

    flowchart TD
    subgraph R1[""]
        direction LR
        BC1["Order Bounded Context<br/>order, payment, and delivery flow<br/>Order, Payment, Delivery"]
        BC2["Product Bounded Context<br/>product, inventory, and catalog<br/>Product, Stock, Catalog"]
        BC3["Customer Bounded Context<br/>membership, auth, and grade<br/>Customer, Auth, Grade"]
    end
    subgraph R2[""]
        direction LR
        UBIQLANG["Ubiquitous Language<br/>a shared vocabulary between<br/>domain experts and developers"]
        CMAP["Context Map<br/>defines relationships<br/>between Bounded Contexts<br/>ACL, OHS, Conformist"]
    end

    style BC1 fill:#E3F2FD,stroke:#1976D2,color:#000
    style BC2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style BC3 fill:#FFF3E0,stroke:#F57C00,color:#000
    style UBIQLANG fill:#E8F5E9,stroke:#388E3C,color:#000
    style CMAP fill:#FFEBEE,stroke:#D32F2F,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

Concept	Definition	Link to MSA
Bounded Context	The boundary within which a single domain model applies consistently	Criterion for separating microservice boundaries in MSA
Ubiquitous Language	A common vocabulary used consistently by everyone within a Bounded Context	Unifies code, API, and DB column names around domain language
Context Map	Defines the relationships and integration methods between Bounded Contexts	ACL (Anti-Corruption Layer), OHS (Open Host Service), Conformist
Shared Kernel	A common model area shared by two Bounded Contexts	Separated and managed as a shared domain library

b. Tactical Design — Aggregate, Entity, Value Object

    flowchart TD
    subgraph AGG["Aggregate"]
        direction TB
        AE["Aggregate Root<br/>Order"]
        E1["Entity<br/>OrderLine<br/>has a unique identifier"]
        E2["Entity<br/>ShippingInfo<br/>has a unique identifier"]
        VO["Value Object<br/>Money<br/>immutable, no identifier"]
        AE --> E1
        AE --> E2
        AE --> VO
    end

    DE["Domain Event<br/>OrderPlaced, OrderCancelled<br/>publishes the fact of a state change"]
    REP["Repository<br/>interface for persisting<br/>and retrieving an Aggregate"]
    SVC["Domain Service<br/>domain logic that doesn't<br/>belong to a single Entity"]

    AGG --> DE
    REP --> AGG
    AGG --> SVC

    style AGG fill:#E3F2FD,stroke:#1976D2,color:#1E3A5F
    style DE  fill:#FFF3E0,stroke:#F57C00,color:#000
    style REP fill:#E8F5E9,stroke:#388E3C,color:#000
    style SVC fill:#F3E5F5,stroke:#7B1FA2,color:#000

Building Block	Definition	Characteristics
Aggregate	A cluster of related objects grouped as a unit of data change	Internal access allowed only through the Aggregate Root
Aggregate Root	The entry point of an Aggregate, responsible for guaranteeing consistency	The only object referenceable from outside
Entity	Has a unique identifier (ID) and changes state over its lifecycle	The same ID means the same Entity even if attributes differ
Value Object	An immutable object defined only by its attribute values, with no identifier	Money, Address, DateRange, etc.
Domain Event	A significant occurrence in the domain, named in the past tense	OrderPlaced, PaymentCompleted
Repository	An interface that abstracts storing and retrieving an Aggregate	Isolates the domain from persistence technology (DB)
Domain Service	Domain logic that doesn’t belong to a specific Entity	Logic spanning multiple Aggregates, such as a Transfer

3. Expected Benefits and Application of DDD

Category	Expected Benefits	Application and Practical Use
MSA design	Clear service boundaries based on Bounded Contexts	Agree on domain boundaries via Event Storming workshops, then split MSA services
Maintainability	Separating domain logic from infrastructure technology minimizes the impact of change	Combine with Clean Architecture to apply Dependency Inversion (DIP) for external dependencies
Collaboration efficiency	Ubiquitous Language closes the communication gap between domain experts and developers	Unify API specs, DB schema, and code variable names around domain language
Complexity management	Aggregate boundaries clarify transaction scope and consistency responsibility	Combine with the Saga pattern to implement eventual consistency in distributed environments

CMMI SOLID Principle