Skip to content

Metadata Card

  • Prerequisites: Chapter 12 (Hexagonal & Clean Architecture); Chapter 13 (Monolith to Microservices)
  • Estimated Time: 50 minutes
  • Core Difficulty: Advanced
  • Completion Milestone: Divide Bounded Contexts and use tactical patterns to model a set of microservices

Your Progress

The City of Artisans workshop system keeps growing. The Forge Studio calls an iron part "precision forging," Assembly Studio calls it "transmission skeleton," Quality Inspection calls it "pending inspection class 3."

Three studios, three names. But they're talking about the same thing. Meetings are incomprehensible, data sync fields don't match, and code is full of translation logic like "if from Assembly Studio, the name field corresponds to component.skeleton_id."

Worse: you want to add a "quenching treatment" feature, and find the code scattered across 12 classes in 6 services — nobody can clearly say "who owns quenching." Your Task

DDD (Domain-Driven Design) is a methodology for tackling complex business modeling. It doesn't teach you specific technologies — it teaches you how to understand your business domain, express that understanding in code, and draw clear boundaries to prevent concept pollution.

Required reading: Bounded Context, Ubiquitous Language, Entity vs Value Object Selective: Aggregate design, Domain Events Advanced: Anti-Corruption Layer


First Layer: Strategic Design — Bounded Context & Ubiquitous Language

Bounded Context: the boundary within which a concept has a specific meaning.

Ubiquitous Language: a unified terminology used by both business and development teams within each Bounded Context.

Context Map: documents relationships between Bounded Contexts (Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Separate Ways).

Second Layer: Tactical Patterns — Entity, Value Object, Aggregate

Entity: has unique identity. Identity matters, attributes can change. Value Object: no identity, distinguished by attribute values. Immutable. Aggregate: a cluster of domain objects treated as a unit. Aggregate Root is the only external entry point. Repository: persistence interface for aggregates.

Third Layer: DDD & Hexagonal Architecture

Natural complements. DDD provides tactical modeling tools for the core; hexagonal architecture provides the technical boundary.

Fourth Layer: Anti-Corruption Layer (ACL)

A translation layer between your Bounded Context and an external system. Prevents external system's chaotic model from polluting your clean domain model.


Common Pitfalls: Treating database tables as aggregates, Bounded Contexts too granular, Ubiquitous Language not used in oral communication, starting DDD from technology rather than business modeling.


Traveler's Notes

DDD is not a coding technique — it's a thinking tool. Strategic design maps the full business landscape (where there's a consistent language, where a translation layer is needed). Tactical design provides modeling within boundaries: Entity handles identity, Value Object handles data, Aggregate handles consistency, Repository handles persistence, Domain Events handle context communication.

Chapter 12's hexagonal architecture gives you the technical inner-outer boundary; DDD gives you the business concept boundary. Together, every layer of your system — from technology to concept — has a clear line of separation.


End of Volume VI.

Built with VitePress | Software Systems Atlas