Practical Domain-Driven Design (DDD) Modeling: Concepts, Strategic & Tactical Design, and Four‑Color Modeling

Before diving into DDD, it is essential to understand that Domain‑Driven Design (DDD) is a methodology that simplifies complex problems by dividing them into manageable parts, aligning business domains with system boundaries, and supporting microservice architecture.

DDD consists of two complementary layers: strategic design , which focuses on business‑level domain modeling and boundary definition, and tactical design , which deals with engineering‑level architecture and model implementation such as DDD/CQRS, clean architecture, hexagonal architecture, etc.

Strategic design is considered more important because it clarifies business boundaries, reduces coupling, and serves as a bridge between product requirements and code.

Key strategic analysis techniques include:

Ubiquitous Language : defining shared terminology to delimit bounded contexts.

Event Storming : collaborative brainstorming to discover domain events and objects.

Four‑Color Modeling : using time‑stamp, PPT, role, and description archetypes to classify concepts.

Paper‑Based Modeling : sketching tables and instances with pen and paper.

DCI Modeling : role‑playing models that promote high cohesion and low coupling.

Tactical design concentrates on two main directions: model design (e.g., choosing rich vs. anemic models) and architecture design (e.g., DDD/CQRS, clean, hexagonal, DCI).

DDD’s importance lies in guiding business design, ensuring code consistency with domain logic, and simplifying maintenance by keeping models lightweight yet comprehensive compared to traditional database modeling.

The core DDD elements are:

Domain : the problem space divided into sub‑domains, core domains, generic domains, and supporting domains.

Aggregate : a cluster of entities and value objects with an aggregate root, typically mapped to a microservice.

Bounded Context (BC) : a linguistic and technical boundary that groups related aggregates, promoting high cohesion within and loose coupling between contexts.

Common challenges in domain modeling include domain discovery, domain partitioning, and identifying aggregates, roots, entities, and value objects.

The article then introduces Four‑Color Modeling as a visual technique to present domain models, describing the four archetypes (Moment‑Interval, PPT, Role, Description) and the four steps to build them: create time‑stamp prototype, PPT prototype, role prototype, and description prototype.

A practical e‑commerce DDD case study is presented, showing financial and payment domain models, highlighting modeling details such as color‑coded prototypes, omission of audit fields, use of DCI for interaction arrows, bolding of unique attributes, and red markers for pending changes.

Finally, the article emphasizes that domain models require ongoing maintenance and that future topics will cover DCI modeling and architecture in more depth.