DDD
Domain-Driven Design splits the domain (business) logic into defined spheres of knowledge. It was originally defined by Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software as the three principles:
- Focus on the core domain its logic.
- Base complex designs on models of the domain.
- Collaborate with domain experts to improve the application model and resolve domain-related issues.
DDD is declarative: programming in this model is effectively creating a domain-specific language for your problem domain.
When to use it
Advantages:
- Eases communication by enforcing common language and constraining interaction between contexts.
- Flexibility achieved through encapsulation and modularity via effective use of object-oriented design.
- Domain over interface avoids ill-fitting abstractions and helps to keep the application understandable to its audience.
Disadvantages:
- Requires robust domain expertise throughout the development lifecycle.
- Encourages iterative practices.
- Poorly suited to highly technical projects, as domain experts may be unable to appreciate the technical challenges associated with a domain.
Terminology
- The Context is the setting in which a word or statement appears which defines its meaning -- statements about a model can only be understood in a context.
- A Model is a system of abstractions that describe and can solve problems within selected elements of a domain.
- Ubiquitous Language is language structured around the domain model used by all members of the team to connect all of the activities of the team with the software.
- A Bounded Context describes a boundary (e.g. a subsystem, module or team's scope) within which a particular model applies.
Concepts
- An Entity is an always-consistent object that describes a domain model.
- A Value Object is an immutable object with attributes, but no identity.
- Domain Events are objects used to record discrete events related to model activity domain experts care about.
- Aggregates are clusters of Entities and Value Objects contained in a defined boundary, which can interact with the rest of the system through a single Aggregate Root. These allows separation of contexts.
- A Service contains functionality that doesn't fit directly within an Entity or Value Object.
- Repositories provide methods for creation, modification and deletion of objects within an Aggregate, centralising business logic outside of the model.
- Factories encapsulate the logic for creation of complex objects and Aggregates.
Backlinks