Key Takeaways

• Aggregates should be based on domain invariants.
• Aggregates should be modified with their invariants completely consistent within a single transaction.
• Qualify associations by adding constraints to reduce technical complexity.
• Aggregates represent domain concepts, not just generic collections of domain objects.
• Aim for smaller aggregates to reduce transactional locking and reduce consistency complexities

Introduction

In domain driven design, a domain model’s structure is composed of entities and value objects that represent concepts in the problem domain. But, handling associations between domain objects is the main reason for complexity and confusion. If you’ve ever worked on large applications, you should see lots of complex domain objects.

If your design does not have any clear notion of simplifying techniques, these associations may grow out of control, and if your object model has a large network of associations, association objects of one object might result in loading large clusters of objects in memory. With modeling like this, there is just no limit to which area of the domain model might be affected. Even though in the real world, at the highest level of your system, all of these things really do interrelate, we need to be able to separate them to keep the complexity of the system in check.

In this case, simplifying complex object graphs is mandatory; They complicate implementation and maintenance. Since the main purpose of the domain model is to support invariants and uses cases rather than user interfaces and domain models are not the same as data models. They should have more communicative and more applicable associations and be consistently constrained as much as possible. The main target is keeping the relationships between domain objects simple and aligned with domain invariants.

This is the main reason why designing relationships between domain objects is equally as important as designing the domain objects themselves. Even when all associations in a model are justified, a large model still has technical challenges, making it difficult to choose transactional and consistency boundaries that both reflect the problem domain and perform well. It is important that you guarantee the consistency of changes in a model with complex associations.

The main issue is how we should represent every conceivable relationship possible in our object model. Where do we draw the line between whether or not to create a reference? If I have a reference between two entities, how should you handle persistence? Do updates cascade?

What Is an Aggregate in Domain-Driven Design

Aggregates consist of one or more entities and value objects based on domain model invariants that change together. We need to treat them as a unit for data changes, and we need to consider the entire aggregate consistency before we apply changes. Every aggregate must have an aggregate root that is the parent of all members of aggregate, and it is possible to have an aggregate that consists of one object. In this case, that object would still be the aggregate root.

An aggregate root is an entity that has been chosen as the gateway into the aggregate. An aggregate root coordinates all changes to the aggregate, ensuring that clients cannot put the aggregate into an inconsistent state. It upholds all invariants of the aggregate by delegating to other entities and value objects in the aggregate cluster.

Also, Aggregates help us simplify the domain model by gathering multiple domain objects under a single abstraction around domain invariants that act as consistency and concurrency boundaries. This concept includes several implications. First of all, it is a conceptual whole meaning that it represents a cohesive notion of the domain model. Every aggregate has a set of invariants which it maintains during its lifetime. This means that at a given time, an aggregate should reside in a valid state.

Data changes in aggregate should follow ACID: atomic, consistent, isolated, and durable. when considering whether a particular object should be treated as an aggregate root you should think about whether deleting it should cascade, in other words, if you need to also delete other objects in the aggregate hierarchy, if so it’s likely the object should be considered as an aggregate root. Another way to think about whether it makes sense to have an object as an aggregate root is to ask does it makes sense to have just this object detached from its parents?

Just like entities and value objects, there are no objective traits that make particular boundaries for aggregate and they fully depend on the domain model you are working in. Actually, The most important rule to define a boundary for your aggregate cluster is that the boundary should be base on domain invariants. Domain invariants are business rules that must always be consistent. The consistency boundary logically asserts that everything inside adheres to a specific set of business invariant rules no matter what operation is performed. The consistency of everything out of the boundary is irrelevant to the aggregate.

Entities inside the same aggregate should be highly cohesive whereas entities in different aggregates should maintain loos coupling among each other, it is good practice to ask your self following question according to your invariants does an aggregate make sense without some other entities, if it does then it should probably be the root of its own aggregates; otherwise, it should be a part of some other existing aggregate. Since entities are encapsulated within aggregates.

They make up the design and implementation of an aggregate’s behaviors. But It would rather have most of the behaviors tied to value objects rather than entities. One of the things I’d encourage is to keep entities free of behavior where possible, since identity is already a big burden to bear, and have behavior expressed in the value objects. So as more behavior needs to be added, I would try to model that as behaviors on new or existing value objects where possible.

#microservices #domain driven design #object graphs