Core Process of Domain‑Driven Design: From Global Analysis to Domain Modeling

Core of Domain‑Driven Design: Model‑Driven Design and the Domain Model

System Context, Bounded Context, Layered Architecture and Aggregates are DDD boundary‑control mechanisms; they differ in the granularity and dimension of business partitioning.

Unified Process of Domain‑Driven Design

“Humans solve problems by searching for solutions in the problem space.”

Similarly, constructing a software system is solving the problem space to obtain design solutions.

The problem space emphasizes describing requirements with a unified language and decomposing it into core, generic, and supporting sub‑domains.

In the solution space, these sub‑domains are mapped to bounded contexts, each choosing a modeling style (e.g., domain modeling for core sub‑domains, transaction script for supporting sub‑domains).

Note: Sub‑domains belong to the problem space, while bounded contexts belong to the solution space; they map to each other.

Within a bounded context, a layered architecture isolates the domain model to achieve separation of concerns, keeping technical and business changes confined to their respective layers.

The strategic design stage of DDD centers on bounded contexts, guiding architectural design; the layered architecture then determines the technical architecture.

The core goal of DDD is to bind business and application architectures while reducing coupling with the technical architecture, enabling the application layer to adapt to business changes and isolate business complexity from technical complexity.

The complete DDD process is divided into three major stages:

Global Analysis Stage – analysis of real‑world problems.

Architecture Mapping Stage – bridging real‑world problems to software solutions.

Domain Modeling Stage – further analysis and modeling of the software solution.

Global Analysis Stage

Goal: Visual exploration and analysis of the problem space.

Tasks: Conduct value‑requirement analysis and business‑requirement analysis to deeply dissect the problem space.

Activities: Value requirement analysis, business requirement analysis.

Deliverable: Global analysis specification document.

Value Requirement Analysis

Stakeholders, system vision, and system scope together form the value requirements, corresponding to the Who, Why, and Where of the 5W model.

Identify the system’s stakeholders (Who).

Unify stakeholder business goals to clarify system boundaries and direction.

Define system vision (Why) and system scope (Where).

Pattern: Unified Language

Method: Business Model Canvas

Business Requirement Analysis

Value requirement analysis guides business requirement analysis. Business requirements consist of dynamic business processes and static business scenarios/services; the latter are split by time points and business goals.

The analysis can be performed at three levels:

Level 1: Business Process

Level 2: Business Scenario

Level 3: Business Service

Each level helps identify core, generic, and supporting sub‑domains.

Visualization: Business Process Diagram, Service Blueprint, Business Service Diagram, Event Storming.

Business Process

At the first level, under business goals, the dynamic business process that delivers value is identified (the "When" of the 5W model). It starts with a role requesting a service and involves multiple roles, featuring time attributes, multi‑role participation, and business value output.

Key points: completeness (end‑to‑end collaboration) and boundaries (scope of business value).

Visualization: Business Process Diagram, Service Blueprint.

Business Scenario

A scenario is the spatiotemporal context where roles interact to achieve a common business goal; it slices the business process by time into distinct scenarios, each possibly involving multiple roles.

Difference & Relation: A dynamic business process consists of one or more static business scenarios; the process is the full end‑to‑end collaboration, while scenarios are time‑based slices guided by business goals.

Visualization: Use‑case Diagram.

Business Service

The third level represents a functional interaction of a role within a business scenario. Business services are the basic units of the global analysis stage and belong to the 5W model’s "What".

Core sub‑domain: services that provide core value to stakeholders.

Generic sub‑domain: services that support multiple domains without distinct characteristics.

Supporting sub‑domain: services that provide auxiliary value.

Architecture Mapping Stage

The solution is derived from three perspectives—organization, business, and system—and mapped to architectural solutions, often illustrated with the first level of C4 diagrams.

Organization‑Level Mapping

Goal: Define the System Context. Using the results of value‑requirement analysis, a system‑context diagram shows stakeholders, the target system, and surrounding systems.

Pattern: System Context

Method: System Context Diagram, Business Sequence Diagram.

Business‑Level Mapping

Goal: Define Bounded Contexts. Business services are grouped and classified to form bounded contexts. Inside each bounded context, a symmetrical diamond architecture organizes data and services; between bounded contexts, the Bounded‑Context Mapping pattern resolves collaboration.

Four design elements of a bounded context: minimal completeness, self‑fulfillment, stable space, independent evolution.

Pattern: Bounded Context, Context Mapping, Diamond‑Shaped Symmetrical Architecture

Method: V‑shaped Mapping Process, Event Storming, Service Sequence Diagram, Conway’s Law, Domain‑Specific Teams.

Bounded‑Context Mapping Patterns

Eight typical patterns for mapping bounded contexts:

Customer/Supplier

Shared Kernel

Conformist

Separate Ways

Open Host Service

Published Language

Anti‑Corruption Layer

Big Ball of Mud

System‑Level Mapping

Goal: Establish a Layered Architecture within the system context. Typical layers include presentation, application, domain, and infrastructure.

Pattern: Core, Generic, Supporting Sub‑domains, System Layered Architecture

Method: Conway’s Law.

Domain Modeling Stage

Goal: Build the domain model inside each bounded context.

Domain modeling consists of three sub‑phases: Domain Analysis Modeling, Domain Design Modeling, and Domain Implementation Modeling.

Domain Analysis Modeling

Guided by a unified language and using the Rapid Modeling Method, business services are abstracted into a domain analysis model.

The Rapid Modeling Method extends the "Noun‑Verb" technique with four steps:

Noun Modeling – identify nouns in service specifications as candidate domain objects.

Verb Modeling – identify verbs as candidate domain behaviors; process data generated by behaviors become domain concepts.

Inductive Abstraction – abstract concepts with modifiers.

Relationship Determination – define relationships among domain concepts.

The output includes a business‑service specification and a domain‑concept diagram.

Domain Design Modeling

Design the complete business service to obtain a domain design model, producing static class diagrams centered on aggregates and dynamic sequence diagrams.

Method: Role‑Based Construction, Service‑Driven Design.

Domain Model Design Elements

Key elements include:

Entity – with identity, attributes, and behavior (avoids anemic models).

Value Object – immutable, used as entity attributes.

Aggregate – a consistency boundary grouping related entities.

Domain Service – stateless behavior involving multiple aggregates or external resources.

Domain Event – expresses state changes and can notify other aggregates or bounded contexts.

Repository – abstracts data access, separating persistence from domain behavior.

Factory – manages aggregate creation.

Domain Implementation Modeling

Using Test‑Driven Development (TDD), write code and unit tests to realize the domain model.

Deliverables are production code implementing business functionality and test code verifying it.

Pattern: Unified Language, Model‑Driven Design

Method: TDD, Simple Design, Test Pyramid.