Domain Driven Design, abbreviated DDD, is a methodology where the emphasis is on the business domain, a business domain driven design.
One of the core principles of DDD is that ubiquitous language is used. This means that there is a common language that is used by both developers and domain experts. This serves as the basis for the terminology and structures in conversations, in designs and in the code.
Driven by the business domain and the sharp division of a complex domain into logical subdomains, clear responsibilities also emerge. With DDD, these subdomains are followed in the design of systems. Such a subdomain and/or how it is chosen to manage responsibilities in one system, is called a bounded context in DDD.
In DDD, everything revolves around building a model that directly reflects the business rules and concepts of the domain; everything revolves around good alignment with domain models. CQRS fits well here, because usually different models exist for read and write operations within a complex domain. The command-model in CQRS can, for example, focus on the actual business logic for changing the state, while the query-model is purely optimized for retrieving data.
Event Sourcing is not a requirement for DDD and/or CQRS, but does align very well. In DDD, events are often used to model changes within a bounded context. Event sourcing goes one step further by considering these events as the source of truth. It aligns seamlessly with DDD, because events are domain-specific and meaningful for both the business and development team.
In short, Domain Driven Design provides the conceptual framework, a methodology and the terminology to arrive at good designs driven around a business domain. CQRS and Event Sourcing are architectural patterns that support this well and offer principles for effective implementation.
References
More information about Domain Driven Design:
Wikipedia about Domain Driven Design
AxonIQ Docs | Domain Driven Design
AxonIQ is the company behind the Axon Framework, a Java framework for building Event Sourcing systems. Read for example:
Books:
- “Patterns, Principles, and Practices of Domain Driven Design” by Scott Millett and Nick Tune
- “Implementing Domain Driven Design” by Vaughn Vernon