Domain-Driven Design
What is it?
Domain-driven design is an approach that structures software around the real business domain, using a shared language between developers and domain experts.
Explain like I'm 5
Why was it created?
Complex business software often drifts from how the business actually works. DDD was created to keep the code aligned with the domain and its experts.
Where is it used?
- Complex business systems
- Defining service boundaries
- Aligning code with the business
- Large team collaboration
Why should developers care?
DDD guides large, complex systems and shapes architecture choices like microservice boundaries, making it valuable for senior roles.
How does it work?
Teams build a shared 'ubiquitous language' with domain experts and model the domain in code. They split the system into bounded contexts — areas with their own consistent model — and use building blocks like entities, value objects, and aggregates.
Real-world example
In an insurance system, 'Policy' and 'Claim' are modeled as rich domain objects, and billing and claims are separate bounded contexts with their own models.
Common use cases
- Modeling complex domains
- Defining microservice boundaries
- Aligning teams and code
- Managing large systems
Advantages
- Code reflects the business
- Shared language reduces miscommunication
- Clear boundaries (bounded contexts)
- Manages complexity
Disadvantages
- Overkill for simple apps
- Steep learning curve
- Needs domain-expert access
- Can be misapplied as buzzwords
When should you use it?
For complex domains where aligning software closely with the business pays off.
When should you avoid it?
For simple CRUD apps where the heavy modeling adds little value.
Alternatives
Related terms
Interview questions
Beginner
- What is domain-driven design?
- What is a ubiquitous language?
Intermediate
- What is a bounded context?
- What's an entity versus a value object?
Senior
- How does DDD inform microservice boundaries?
- When is DDD not worth the overhead?
Common misconceptions
- "DDD is just for microservices" — it's about modeling the domain; it informs but isn't tied to microservices.
- "DDD is only about tactical patterns" — its biggest value is the strategic work: language and bounded contexts.
Fun facts
- The term comes from Eric Evans's 2003 book.
- Bounded contexts often map naturally to microservice boundaries.
Timeline
- 2003 — Eric Evans publishes the Domain-Driven Design book
Learning resources
Quick summary
Domain-driven design structures software around the business domain with a shared language and bounded contexts, taming complexity in large systems.
Cheat sheet
- Model the business domain
- Ubiquitous shared language
- Bounded contexts
- For complex domains, not simple CRUD