Aggregation and Aggregate Roots of Domain Driven Design
After the association design of entities and value objects, etc., it is necessary to divide the aggregation and determine the aggregation root.
First of all, we need to clarify why we need to divide the aggregation?
It turns out that the smallest unit that our system divides the field is usually the module, such as the customer information management module and the employee information management module. However, the division of modules is still too coarse-grained for design.
1. Aggregation and Aggregate Roots
1. Define clear relationships and boundaries between objects and achieve cohesion of the domain model. My understanding is that only objects in an aggregate have strong associations, and the association design of objects should be between entities and entities or entities and value objects in an aggregate. (For example, in the field of placing an order, order (entity), order item (entity) and order status (value object) should be an aggregate, order is associated with order item, and order is associated with order status).
2. Aggregates must be treated as a unit of modifying data.
3. An aggregate must have an aggregate root. The root is an entity in the aggregate. Usually other entities in the aggregate need to depend on the aggregate root. Other entities cannot exist alone without the aggregate root. From a business point of view, it does not exist alone. meaning. For example, in point 1, the order should be the aggregate root, because the two objects, order item and order status, are meaningless without an order.
4. An access or operation to an entity in an aggregate must start through the aggregate root of the aggregate. The main purpose is to ensure constant consistency rules. For example, in point 1, the order has an order total attribute, the line item has an attribute of the current item amount, and there is a rule that the order total is the sum of the order item total, if other aggregation bypasses the order aggregation root and directly operates the line item entity, after the operation, it is difficult to ensure the same consistency rules. If the order items are operated through the order aggregation root, and the order aggregation root is responsible for the consistency of business rules, this can be guaranteed. Therefore, an important responsibility of the aggregate root is to maintain the internal consistency of the aggregate.
5. When querying or operating an aggregate, the entire aggregate is taken as a whole, and a non-root object within the aggregate cannot be directly queried.
2. Identify aggregation
Recognition aggregation After theoretical and practical project development, I think aggregation should be divided from the following aspects
1. Which entities or value objects together can effectively express a domain concept.
2. Whether some fixed rules must be maintained between objects.
3. Do not design the aggregation too large, otherwise there will be performance problems and business rule consistency problems.
4. Entities and value objects in an aggregate should have the same life cycle and should belong to a business scenario.
3. Identifying Aggregate Roots
1. An aggregate has only one aggregate root. The aggregate root can exist independently. Other entities or value objects in the aggregate depend on the aggregate root.
2. Only the aggregate root can be accessed externally, and the aggregate root maintains the internal consistency of the aggregate.