In 30 seconds
- Model the software on the real business domain.
- Developers and domain experts share one ubiquitous language.
- Split large systems into bounded contexts.
Core ideas
- Ubiquitous language: the same terms in conversation and in code
- Bounded contexts: clear boundaries where a model applies
- Context map: how bounded contexts relate
Eric Evans introduced DDD in his 2003 book Domain-Driven Design.
Building blocks
| Block | Meaning |
|---|---|
| Entity | Object with an identity, like a customer |
| Value object | Defined by its values, like money |
| Aggregate | A cluster treated as one unit for changes |
| Domain event | Something meaningful that happened |
When it's worth it
DDD pays off in complex business domains with rich rules. For simple CRUD apps it's usually overkill. Bounded contexts are often used to draw microservice boundaries.
Myth vs reality
Myth · DDD is about patterns and code.
Reality · The shared language and model come first.
Myth · Every project needs DDD.
Reality · Simple domains don't benefit much.
Myth · One model should cover the whole company.
Reality · Different contexts need different models.
FAQ
What's event storming?
A workshop technique for exploring a domain using sticky notes for events.
Do we need domain experts?
Yes; DDD depends on close collaboration with them.
How does DDD relate to microservices?
Bounded contexts are a good guide for service boundaries.