// Learning · 05
Domain-Driven Design
Model the business in its own words, and draw the boundaries where the words change.
What is it?
A domain is the area of business your software serves: insurance claims, shipping, payroll. Domain-Driven Design (Eric Evans, 2003) is a way to build software for a complicated domain. Developers and the people who know the business, the domain experts, work out a model of it together, name everything in their shared words, and make that model the heart of the code.
How it works
It works at two levels. Strategic design decides where the boundaries go: which parts of the business matter most (subdomains), where a word changes meaning (bounded contexts) and how those contexts depend on each other (the context map). Tactical design is the toolkit inside one context: entities, value objects, aggregates, domain events, repositories and services.
Start strategic. Most of the value is in the language and the boundaries; the tactical patterns pay off inside a core subdomain with real rules to protect. Event Storming is the usual way to discover both.
The big picture
- Domain experts creates Ubiquitous language (1 shape)
- Ubiquitous language uses / calls Sales context (2 names)
- Sales context publishes / notifies Billing context (3 context map)
- Sales context wraps / holds Order aggregate (4 zoom in)
- Order aggregate creates OrderPlaced (5 raises)
- Order aggregate wraps / holds Money
- OrderRepository uses / calls Order aggregate (6 persists)
Reach for it when
- The rules are complex and keep changing
- Developers and experts use different words
- One model is stretched across teams
Skip it when
- Mostly forms over a database (CRUD)
- Nobody who knows the business is available
- A generic problem you could buy instead