Aggregation (root), Entity, value object Refining thinking Summary

1. What are the differences between aggregate root, entity, and value objects?

From the perspective of the identity:

The aggregate root has a globally unique identity, and the entity only has a unique local identity within the aggregation, the value object does not have a unique identity, and there is no argument for the value object or the value object;

From whether read-only angle:

Aggregations eradicate unique identities, all other state information is theoretically variable, entities are mutable, and value objects are read-only;

From the life cycle perspective:

The aggregation root has an independent life cycle, and the entity's life cycle belongs to the aggregation to which it belongs, and the entity is responsible for the management of maintenance by the aggregation root it belongs to; The value object has no life cycle, because it is just a value;

2. How are the associations between aggregate root, entity, and value object objects established?

aggregate root to aggregate root: by ID Association;

Aggregates the root into its internal entities, direct object references;

Aggregate root to Value object, direct object reference;

The entity's reference rule to other objects:1) can refer to the aggregate root, entity, value object within the aggregation it belongsto, 2) can reference an external aggregate root, but it is recommended to be associated with an ID, or it can be associated with an entity within an external aggregation, but it must be an ID association. Otherwise, a reference to the same entity is held by two aggregate roots, which is not allowed, and a reference to an entity can only be held by the aggregation root to which it belongs;

Value object reference rules for other objects: just make sure that the value object is read-only, and that all properties of the recommended value object are as value objects as possible;

3. How do I identify aggregation and aggregation roots?

Explicit meaning: A bounded context (defined contexts) may contain multiple aggregations, each of which has a root entity, called the aggregate root;

Identification Order: First find out which entities may be the aggregate root, and then analyze the boundaries of each aggregate root, that is, which entities or value objects the aggregate root should aggregate, and then divide bounded Context;

Aggregation Boundary Determination rule: According to invariant constraint rules ( Invariant). There are two types of invariant rules:1) What information must be in the aggregation boundary, and if no such information is not known as a valid aggregation;2) The state of some objects within the aggregation must satisfy a business rule;

Example Analysis 1 : Order model

Order(A orders) must have corresponding customer information, otherwise it cannot be called a validOrderIn the same vein, Order has a invariance constraint on the Orderlineitem,OrderThere must also be at least oneOrderlineitem (an Order detail), no It is not called a validOrder; In addition,Orderany of theOrderlineitemcan not be the number of0, otherwise consider theOrderlineitemis invalid at the same time can infer theOrdermay also be invalid. Because if you allow aOrderlineitemthe number is0, that means that it may appear that allOrderlineitemthe number is0, which leads to the entireOrder's Total Price is0That it was meaningless, was not allowed, and thus ledOrderTherefore, it must be requested.Orderin all theOrderlineitemcan not be the number of0so now it's OK toOrdermust contain someOrderlineitem, then it should be through the way to cross-reference is stillIdHow do you relate to this containment relationship? This leads to another problem, which is to first analyze theOrderlineitemwhether it is a separate aggregation Root. Answer this question, then according to the above rules will know whether to use the object reference orIdassociated with. SoOrderlineitemis it an independent aggregation root? Because the aggregation root means flavor is the root of an aggregation, which represents a context boundary, and a context boundary represents a separate business scenario, and the only object that the business scenario operates on is always the aggregation within that context boundary Root. When we think about it, we can think about whether there is any scenario that would bypass an order and directly manipulate an order detail. In this case, we is toOrderlineitemas the main body, completely in the face ofOrderlineitemin doing business operations. Is there such a business scenario? No, we're right.Orderlineitemall of the operations are based onOrderas a starting point, we will always face the wholeOrderDoing business operations, such asOrderAdd details, modifyOrderThe purchase quantity of a product corresponding to a particular detail, fromOrderto remove a detail, and so on, we neverOrderlineitemTo carry out some business as a starting point and, in addition, from a life-cycle perspective,OrderlineitemLeaveOrderThere is no sense of existence, that is to sayOrderlineitem's Life Week period is from belonging toOrderthe. So, we can be very sure of the answer,Orderlineitemis an entity.

Example Analysis 2 : Make a comparison between the post and the response model in order to better understand it.

No denaturing Analysis: Are there any invariance rules between posts and replies? It seems that we only know one thing for sure, that is the relationship between the post and the reply,1:NApart from this, we do not see any other invariant rules. So this1:Nis the object relationship an invariant rule? No! First of all, a post can have no reply, the Post also does not have any rule to its reply, it does not even know from how many replies have been made; again, there is no relationship between a reply and a post, and secondly, there is no change to the post; From the perspective of the business scenario, we have a post-posting scenario, a post reply to the scene. When the reply is posted, the reply is the main, the post is only the necessary information contained in this reply, to explain the reply is the reply to which post. These all indicate the post and the reply Cannot find any rules for invariant constraints, because posts and replies have their own separate business scenarios, so it's easy to understand that they are independent aggregation roots; it's also easy to know how to build their Association , but we want to minimize the association, so only the reply to the link to the post, the post does not have any need to save a reply to theIdthe list; then you might say when I delete a post , the reply should be no meaning of existence? No, there is no meaning, but the deletion of the post resulted in a reply to the Post's associated information missing, resulting in inconsistent data. This is because posts and replies There is an inevitable connection between the1:N), the reply must have a corresponding post, but the reply has its own life cycle, should not be deleted as the post is deleted. In this case, if you delete the Post, which causes the reply to also become an invalid data; Therefore, we are not allowed to delete any aggregate root, because once you delete the aggregate root, it means that any other aggregate root associated with that aggregate root will The problem that the foreign key reference is missing will result in the inconsistency of the whole domain model data; Therefore, never delete the aggregate root;

Aggregation (root), Entity, value object Refining thinking Summary