Domain-driven design cheatsheet
Any good cheatsheet offers support when you need it. This one summarises the most fundamental parts of domain-driven design, also known as DDD. It’s divided into two parts, strategic and tactical design.
In short, strategic design addresses the what and the why of a software development endeavour. Strategic design applies the principle of separation of concerns iteratively on a business domain. This process is called distillation. Its aim is to provide engineers what they need to design bounded contexts. A natural starting point for the distillation is a company’s organisational units such as departments.
business domain = a company’s area of activity
subdomain = by analysis identified subset of the business domain
bounded context (BC)= by engineers designed software solution for which a ubiquitous language has been developed
ubiquitous language = shared vocabulary between engineers and the business-side scoped to a BC
Addresses the how for a software solution.
strong consistency = when mutations of state are atomic e.g. changes made in a database transaction
eventual consistency = when mutations of state are not atomic e.g. changes made sequentially in two µservices’ databases as part of a unit of work
- Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley.
- Khononov, V. (2021). Learning Domain-driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media, Inc.
- Evans, E. (2015). Domain-Driven Design Reference. Domain Language, Inc.