Domain-Driven Design
Software design approach centering development on the business domain, using a ubiquitous language shared between developers and domain experts.
seed#ddd#domain#bounded-context#aggregates#architecture#modeling
What it is
Domain-Driven Design (DDD) is a software design approach that prioritizes modeling the business domain. The premise: real complexity is in the domain, not in technology. DDD provides patterns to handle that complexity.
Strategic concepts
- Bounded Context: explicit boundary where a domain model is consistent
- Ubiquitous Language: shared vocabulary between devs and business
- Context Map: relationships between bounded contexts
- Subdomain: business area (core, supporting, generic)
Tactical concepts
- Entity: object with unique identity
- Value Object: object defined by its attributes (immutable)
- Aggregate: cluster of entities with a root
- Repository: persistence abstraction
- Domain Event: something that happened in the domain
- Domain Service: logic that doesn't belong to an entity
DDD and microservices
DDD bounded contexts naturally map to microservices. Each microservice implements a bounded context with its own model and data.
When to apply DDD
| Situation | DDD? | Alternative |
|---|---|---|
| Complex domain with rich business rules | Yes — DDD shines here | — |
| Simple CRUD without business logic | No | Traditional layered architecture |
| Team without access to domain experts | Partial — tactical patterns without strategic | — |
| Startup in exploration phase | No — too much ceremony | Simple modules, refactor later |
| Legacy system being migrated | Yes — bounded contexts guide decomposition | Strangler fig |
Common mistakes
- DDD without domain experts: ubiquitous language requires real conversations with the business, not assumptions from the technical team
- Bounded contexts too small: a bounded context is not a microservice by default — it can contain multiple services
- Aggregate roots too large: if an aggregate has more than 3-4 entities, it probably needs decomposition
- Ignoring the context map: relationships between bounded contexts (customer-supplier, conformist, anticorruption layer) are as important as the contexts themselves
Why it matters
DDD provides a language for aligning code with the business domain. In complex systems, bounded contexts define clear boundaries between teams and services, avoiding the coupling that turns monoliths into systems impossible to modify.
References
- Domain-Driven Design — Eric Evans, 2003. The original book.
- Implementing Domain-Driven Design — Vaughn Vernon, 2013.
- DomainDrivenDesign — Martin Fowler, 2020. Summary of the DDD concept.