The Two Sides of Domain-driven Design
How to apply top-down and bottom-up
It's common to only know about and apply one of these ๐
๐ฆ
๐๐ญ๐ซ๐๐ญ๐๐ ๐ข๐
On a business level, Domain-driven design (DDD) is all about absorbing domain information from your subject-matter business experts in a manner that aids engineering efforts.
Your business experts understand what is valuable. Your engineering experts understand how it can be delivered.
In practical terms this often clashes at one area: scoping.
Your engineers know how to slice pieces so that delivery can be accelerated in iterations, but they have no insights whether an isolated slice actually captured (or invalidated) the valuable parts.
Your domain experts suspect what is most valuable but have no idea along what axis to slice it. To them, itโs not clear if cutting features this way or that way accelerates or impedes development.
Benefits of figuring out collaboration are plentiful:
๐ Develop a common language that allows you to use your real-world terminology in your code
๐ Discover boundaries where your system splits in behavior for topics that are named similarly (noun re-use, e.g. customer, order)
๐ Help domain experts share knowledge between each other to expose gaps in knowledge
๐ Empower non-engineering parts of the business to contribute with architecture and implementation details
๐ฏ ๐๐๐๐ญ๐ข๐๐๐ฅ
Zooming into the code level, DDD comes with a preferred set of design patterns and approaches to common business problems.
Often they centre around persistence strategies and decoupling/cohesion:
๐ซ Aggregates capture a clear emphasis on transaction boundaries within your domain model entities
๐ซ Repositories embrace a common interface to invert infrastructure persistence dependencies
๐ซ Value Objects and Domain Events enrich APIs and avoid common code smells like Feature Envy and Primitive Obsession
๐ซ Nouns and verbs extracted from the domain experts help naming components and classes in your system.
๐ซ Naming your disparate modules of code well is the crucial step towards high cohesion.
The WHAT now?
Unfortunately, many developers are tactical-only practitioners without any buy-in from the business. This often leads to mis-used design patterns, no clear understanding of Aggregates and mistaking frameworks and ORMs for being DDD-supportive.
To practically take a leap and start involving business experts into the language-shaping, the suggested industry practice is to conduct Event Storming or Event Modelling sessions for each roadmap planning (more often is better).