02Domain-Driven Design in brief

Domain-Driven Design was introduced by Eric Evans in his 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software. Its premise is simple: in most business software, the hardest complexity is not technical but lies in the domain itself, so the design of the software should follow a model of that domain, built together with the people who know it.

DDD is often reduced to a catalogue of code patterns. That reading misses most of its value. The book, and the work that followed it from Vaughn Vernon, Alberto Brandolini and others, distinguishes two levels of design, and the strategic one matters most for this essay.

Strategic design

Strategic design deals with the large-scale structure of a system: which parts exist, what each one means, and how they relate.

• Subdomains describe the problem space. The core subdomain is where the organisation differentiates itself and where the best people should work. Supporting subdomains are necessary but not distinctive. Generic subdomains, such as identity management or invoicing, are solved problems best bought or reused.
• Bounded contexts describe the solution space. A bounded context is an explicit boundary within which a model, and the language that expresses it, has one consistent meaning. Outside the boundary, the same words may mean something else, and that is acceptable as long as the translation is explicit.
• Context maps describe how bounded contexts relate: who depends on whom, who adapts to whom, and how models are translated at each boundary.

The ubiquitous language

Within each bounded context, DDD asks the team and the domain experts to use a single, rigorous vocabulary, in conversation, in documents, in tests and in code. Evans called it the ubiquitous language. When an expert says "a unit is allocated to a patient", there should be a Unit, a Patient and an allocate operation in the code, with the same meaning and the same rules.

The language is not a glossary written once. It evolves with every conversation, and refining it is how the team deepens its understanding of the domain. Evans called this process knowledge crunching.

Tactical design

Tactical design deals with how a model is expressed in code inside one bounded context: entities with an identity, value objects defined by their attributes, aggregates that protect consistency rules, domain events that record what happened, and repositories and services around them. These patterns are useful, but they are means, not ends. A system can use every tactical pattern and still have no meaningful boundaries.

Table 1 · The main DDD concepts used in this essay.