Mastering DDD Domain Modeling with the Four‑Color Modeling Method

DDD Domain Analysis

Domain‑Driven Design (DDD) is presented as an event‑storming‑driven approach that informs organization, system, and code partitioning. Its essence is to simplify complex problems by dividing them, thereby reducing overall complexity.

DDD aligns with microservice architecture, providing a strategic basis for service boundaries. DDD comprises strategic design (business‑level domain modeling and boundary definition) and tactical design (architectural and model design applied to microservices).

Strategic design : focuses on identifying domain models and boundaries, independent of code implementation.

Tactical design : translates strategic insights into concrete architecture, such as CQRS, clean architecture, hexagonal architecture, or DCI.

The author argues that strategic design is more important because it prevents monolithic growth and keeps business boundaries clear, even when the code follows traditional MVC patterns.

Key Elements of DDD

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

Aggregate : consists of an aggregate root, entities, and value objects; the author uses a rich‑model approach and notes that a microservice should contain at least one aggregate to avoid distributed‑transaction complexity.

Bounded Context (BC) : defines a clear business boundary and a ubiquitous language; each BC maps to a top‑level package in Java code, aims for high cohesion inside and low coupling between contexts, and should communicate via domain events or anti‑corruption layers.

Challenges highlighted include domain discovery, boundary definition, and model identification (aggregates, roots, entities, value objects).

Four‑Color Modeling Method

The four‑color modeling method, originally proposed by Peter Coad and Mark Mayfield (Coad 92) and later extended by David North (Coad 95‑97), provides a visual, multi‑dimensional way to classify domain concepts.

Moment‑Interval (MI) Archetype : captures time‑based events such as orders or invoices (shown in light red).

Part‑Place‑Thing (PPT) Archetype : represents participants (people, things, places) like products or accounts (light green).

Role Archetype : abstracts roles played by people, organizations, or locations (light yellow).

Description Archetype : describes reusable informational resources such as catalogs or payment methods (light blue).

The modeling process consists of four steps:

Establish the MI archetype by identifying traceable events.

Build the PPT archetype to enrich the model with related participants.

Create the Role archetype to abstract entities that can act in multiple processes.

Add the Description archetype to supplement the model with reusable informational objects.

Relationships and core interactions between archetypes are annotated throughout the diagram.

Practical Case Study

The author presents a partial financial‑domain and payment‑center model from an e‑commerce system. The diagrams (included below) illustrate how the four‑color method visualizes domain objects, their aggregates, and bounded contexts.

Design details highlighted in the case study:

Pink elements (MI) correspond to core business data and roughly map to table design.

Model attributes omit generic audit fields (ID, creator, timestamps, soft‑delete flag); only core behaviors are modeled.

Arrows within a BC show core interactions; dashed arrows between BCs indicate cross‑context communication, often using DCI modeling concepts.

Bolded attributes denote business‑unique identifiers, making model intent explicit.

Red highlights mark attributes that are not yet released, signaling pending changes.

URL design avoids embedding BC names to keep controllers flexible for future adjustments.

The author stresses that domain models require ongoing maintenance, similar to code, and that microservice owners must stay aware of model evolution.

Conclusion

DDD bridges product requirements and implementation by establishing a ubiquitous language, clear bounded contexts, and strategic‑tactical alignment. The four‑color modeling method offers a concrete, visual technique to capture domain concepts, traceability, and execution efficiency, enabling teams to communicate effectively and design maintainable microservices.