The UML:
aggregation relationship: the object is an integral part of the member, but the member objects can exist independently from the object as a whole.
The car (Car) and the engine (Engine), the tire (Wheel), the relationship between the lamp (Light) polymerization relationship, the engine, tires, car lights may be present from, for example to a change to another car engine the can.
Combining relationship: said relationships and is an integral part of the overall relationship in the combination but objects can control the life cycle of members of the object, once the whole object does not exist, there is no member objects, objects having between overall objects and members student relationship with the total death.
Therefore, the combination of polymerization and on the point difference: and the whole life cycle of the part are the same, i.e. after the entire die members whether the object can exist separately from the object as a whole.
DDD aggregation relationship:
is also an integral part of the relationship and, in part out of the whole will become meaningless, emphasizing consistent with the total death of the life cycle. Therefore, by definition DDD polymerization and combination relation to be consistent in UML.
According to the above definition, we analyze a typical example is the relationship between the company and the department.
UML angle:
1, a plurality of departments of the company, the overall relationship is satisfied and the portion;
2, and a sector can not be added to the company from other companies;
Therefore, the combination should belong in UML relationship, no problem.
DDD point of view:
While UML-based perspective, companies and departments belonging to the combination of relationship, it is in DDD whether the department should be polymerized in the company below it? My view is that, although from the life cycle, sector can not really off companies.
But DDD aggregation design factors to be considered will be more plentiful, such as:
- DDD emphasis on the needs and Bounded Context, that is, it will be modeled based on the needs and context modeling before we must first determine what are the current needs and context;
- In the current context of whether there is a whole part of the strong concern;
- Are there any rules invariance between the whole and the part;
- Operation whether the service overall scene coincides with the operating portion;
- Performance issues, if part of the overall number of polymerization is too large, it will not consider polymerization, the small aggregation principle;
- Consistency, we designed the system, even if the object is to present the coming together of separate design for multiple polymerization, can go up to solve the consistency of technology, such as to complete the synergy created by multiple aggregation service areas, deleted , modify, and through database transactions to ensure strict strong consistency;
- DDD field modeling domain concepts will be abstract, so then the domain model, perhaps no company, but rather only the department, the company is also seen as a top-level department on the line, so naturally there will be companies that aggregate root a;
So, DDD polymerization during the design, if only from the part will become meaningless (ie life cycle between objects) that point to derive the overall delete, then consider it too thin, is likely to have the unreasonable design of the polymerization.
This is no serious analysis of business needs, no analysis of business rules invariance, no abstract concept of reasonable field, no performance applications OO design principles of software.
I think this is why DDD aggregation design reasons why so hard up.
Therefore, the conclusion is that more the case because the demand is unknown, can not be aggregation design, we are not surprised it? There's no answer :)