Aggregate In DDD

What makes an ENTITY AGGREGATE root Has global identity. Expected to be directly accessed in typical business scenarios. If it has other objects to take care of and: Manage lifecycle of internal objects within it’s boundary. Control all access to internal objects. Enforce invariants/integrity in transactions.

AGGREGATE in modeling process(1) Separate domain LAYERS. Identify ENTITY and VALUE objects in domain layer. Identify AGGREGATE root of ENTITIES and define it’s boundary. Create REPOSITORY for AGGREGATE root.

AGGREGATE in modeling process(2) Consider creation of objects (constructor, AGGREGATE root, FACTORY…). Clarify responsibilities and put objects into proper MODULES and LAYERS. Iteratively discover and refine domain model.

AGGREGATE in codes(1) AGGREGATE root creates internal objects. Part part = root.AddPart(“part-1”); Part part = new Part(root, “part-1”); root.AddPart(part);

AGGREGATE in codes(2) ONLY provide accessibility through REPOSITORY for AGGREGATE root. Other objects must be found by traversal of associations. Nothing outside the aggregate boundary can hold a reference to anything inside, except the root. (deleting operation has no side effects.) ENTITYES inside boundary have local identity, unique within AGGREGATE.

AGGREGATE in codes(3) AGGREGATE root holds internal object related logic for some cases. Objects within AGGREGATE can hold references to other AGGREGATE roots.

Defining boundary(1) Listen to typical business scenarios, be pragmatic on defining boundary. Be referenced by an AGGREGATE root does not mean being aggregated. Entity accessed through different paths (AGGREGATE roots) in different scenarios usually worth making itself it’s own AGGREGATE root.

Defining boundary(2) Use this pattern: "No one would look up A directly without wanting the B itself.” instead of the below one “the A is not integrated/valid conceptually without an B.”

Not mentioned topics NHibernate cascading strategy for AGGREGATE. Typical trade-offs when implementing AGGREGATE.