Notebook
Domain-Driven Design
Putting the problem, not the database, at the centre of the software.
A domain model is a useful account of a problem: the language, decisions, and rules that matter to the people doing the work. Fowler describes Domain-Driven Design as building that understanding into the software, then evolving it through the life of the product.
This notebook follows that work from finding subdomains to modelling behaviour, consistency, identity, persistence, and events. The examples come from real systems, including MiniVerine.
Start at Creating Domains.
In this notebook
- Creating DomainsHow MiniVerine finds Envelope, Messaging, and Sagas inside the larger problem of building a bus.
- Bounded ContextsThe solution boundary you draw once the problem has a name — where a word is allowed to mean one thing.
- Ubiquitous LanguageThe words we share with the people who live the domain, used in speech and in code.
- ModellingChoosing a useful account of the problem that makes its behaviour and decisions explicit.
- AggregatesConsistency boundaries inside a model — what must change together.
- EntitiesThings with identity that can change over time and still be the same thing.
- Value ObjectsValues defined by what they are, not by who they are.
- RepositoriesFinding aggregate roots in the model’s terms without exposing tables.
- Domain EventsSomething that happened in the domain, said in the domain’s own words.
Related, later
These sit next to Domain-Driven Design. They are not pages in this notebook yet.
- Integration Events
- Microservices
- Pub-Sub