Domain-Driven Design (DDD) centers software design on a deep understanding of complex business problems. Stakeholders share that understanding through a model expressed in an unambiguous ubiquitous language. section 2.2.1
DDD organizes design around several connected ideas:
- Domain experts guide the creation of shared understanding among all stakeholders. section 2.2.1
- The ubiquitous language derives from domain language and removes ambiguity from communication. section 2.2.1
- The domain model captures complexity inside the problem space and should be continuously improved as understanding deepens. section 2.2.1
- Bounded contexts establish explicit boundaries within which a model and its language remain consistent. section 2.2.1
- Strategic design addresses organizational alignment, domain discovery, architecture, bounded contexts, and language; tactical design addresses implementation within each bounded context. section 2.2.1
DDD is a mindset rather than a fixed method: understand the problem before proposing software, and continuously question and refine the model. It supplies principles, patterns, tools, and techniques without prescribing one process. section 2.2.1 section 2.2.3
Collaborative modeling provides a practical way to apply DDD. Stakeholders visualize complex domain problems together, shape the ubiquitous language, identify domain boundaries, and compare possible designs. section 2.2 section 2.2.3
Investigating subdomains
A team may focus on a core domain while overlooking supporting or generic subdomains. DDD treats all three as relevant to system design: even a generic Payments bounded context can prevent customers from completing a purchase if neglected. section 6.2.1
