13DDD in name only
How DDD drifts like Scrum, and why bounded contexts are not microservices.
DDD can drift exactly as Scrum does. The visible parts, the patterns, the diagrams, the vocabulary, survive. The essence, a continuous conversation with domain experts that shapes the model, quietly disappears. A combination of Scrum in name only and DDD in name only delivers the cost of both and the benefits of neither.
The common drifts
| Symptom | What was lost | Way back |
|---|---|---|
| Entities, repositories and services everywhere, but no boundaries | Strategic design; the tactical patterns were adopted alone | Start from the context map; use tactical patterns only where the model is rich |
| A context map drawn once by architects and never revised | Empiricism; the map became a big upfront design | Review the map every quarter against the actual flow of work |
| One service per entity, and every feature touching ten services | Cohesion; contexts were cut too fine | Merge contexts that always change together |
| Contexts that mirror the database schema or the org chart | The domain as the source of boundaries | Rediscover the seams with domain experts, through Event Storming |
| A language invented by developers | The domain experts | Bring experts into refinement and the Sprint Review; let them correct the words |
| One enterprise-wide "canonical model" for everything | The bounded context itself | Accept different models in different contexts, with explicit translation |
Table 8 · DDD in name only: symptoms, causes and remedies.
Bounded contexts are not microservices
One confusion deserves a section of its own. Bounded contexts are often equated with microservices, and the equation causes damage. A bounded context is a boundary of meaning: a model and its language. A microservice is a unit of deployment. One context can be deployed as a single service, as several, or as a well-isolated module inside a larger application.
For many products, especially early on or under regulation, a modular monolith with strictly enforced module boundaries is the sounder starting point. It gives the teams the autonomy of separate models without the operational burden of a distributed system, and it keeps the verification scope manageable. Contexts can be extracted into separate services later, when there is a clear reason such as different scaling needs or release cadences. Distributing too early produces the worst of both worlds: a distributed monolith, with the coupling of a single system and the failure modes of many.
The same lesson, twice
The pattern is the same as in Scrum in Name Only. What survives is what is easy to see and easy to copy: ceremonies in one case, code patterns and diagrams in the other. What sinks is what takes sustained effort: goals and honest inspection for Scrum, conversation with domain experts and the evolution of the model for DDD. The remedy is also the same. Restore the purpose first. The practices regain their meaning afterwards.
Section takeaways
- DDD drifts like Scrum: the patterns and diagrams survive while the conversation with domain experts disappears.
- Bounded contexts are boundaries of meaning, not deployment units. A modular monolith is often the right starting point.
- For both disciplines, recovery starts with purpose, not with practices.