Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
These domain experts use company- or industry-standard terminology. In DDD, this vocabulary is called the Ubiquitous Language
I would expect to find corresponding class names in the code.
Bounded Contexts guide you toward thinking of software as a portfolio of models.
Modules help you organize a larger single model into smaller chunks.
Aggregate roots as a technique for organizing small collaborations between a few highly related classes.
In most enterprise systems there are course-grained areas of responsibility. DDD calls this top level of organization a Bounded Context.
Bounded Context to Context Map
A context map encapsulates multiples bounded context
One very important thought about Bounded Contexts: each context owns its own Ubiquitous Language.
Anti-Corruption Layers
An Anti-Corruption Layer (ACL) is another DDD pattern that encourages you to create gatekeepers that work to prevent non-domain concepts from leaking into your model. They keep the model clean.
"At their heart, repositories are actually a type of ACL. They keep SQL or object-relational mapping (ORM) constructs outside of your model."
A System of Single Responsibilities
I've mentioned that DDD provides a pattern language for structuring rich domain models. By implementing these patterns, you get a certain level of adherence to the SRP for free, and that's certainly valuable.
Entities Have an Identity and a Life
An entity is a "thing" in your system. It's often helpful to think about these in terms of nouns: people, places, and, well, things.
"Think of entities as units of behavior rather than as units of data. Try to put your logic in the entities that own them."
Value Objects Describe Things
Value objects are descriptors or properties important in the domain you are modeling.
Value objects are immutable. They are incapable of change once they are created.
"Part of the beauty of value objects is that they describe the properties of entities in a much more elegant and intention-revealing way"
Aggregate Roots Combine Entities
An aggregate root is a special kind of entity that consumers refer to directly. Identifying aggregate roots allows you to avoid over-coupling the objects that comprise your model by imposing a few simple rules. You should note that aggregate roots guard their sub-entities zealously.
The biggest rule to keep in mind is that aggregate roots are the only kind of entity to which your software may hold a reference.
Domain Services Model Primary Operations
Sometimes you have operations or processes that do not have an identity or lifecycle in your domain. Domain services give you a tool for modeling these concepts. They're typically stateless and highly cohesive, often providing a single public method and sometimes an overload for acting on sets.
"When there are a number of dependencies involved in a behavior and I can't find a natural place on an entity to place that behavior, I'll use a service."
Repositories Save and Dispense Aggregate Roots
Repositories represent an in-memory collection, and the conventional wisdom is that you end up with one repository per aggregate root.
Repositories are a good candidate for a super class or what Martin Fowler refers to as the Layer Supertype pattern.
Strategic Design
Describe objects
Core domain
Entities
Tactical Design
"Entities are mutable"
Values objects = unmutables
Aggregate
Repositories(DB) and services(Logic)
Top comments (0)