Domain Driven Design User Group April 2012 Considerations

Domain Driven Design User Group | April 2012 Considerations for Effective Aggregate Design Grappling with the nuances of the Aggregate Root Pattern

Domain Driven Design User Group | April 2012 Agenda • • • Review of the Aggregate Pattern in DDD Coarse-grained Aggregate Designs Fine-grained Aggregate Designs Compound Entity and Value Object Graphs Working with Multiple Aggregates Experiences and Discussion

Domain Driven Design User Group | April 2012 Aggregate Design Pattern “An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. ”

Domain Driven Design User Group | April 2012 Aggregate Design Pattern “If objects of an Aggregate are stored in a database, only the root should be obtainable through queries. The other objects should be obtained through traversal associations. Objects inside an Aggregate should be allowed to hold references to roots of other Aggregates. The root Entity has global identity, and is responsible for maintaining the invariants. Internal Entities have local identity. ”

Domain Driven Design User Group | April 2012 Aggregate Design Pattern “Cluster the Entities and Value Objects into Aggregates and define boundaries around each. Choose one Entity to be the root of each Aggregate, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only. Transient references to internal members can be passed out for use within a single operation only. Because the root controls access, it cannot be blindsided by changes to the internals. This arrangement makes it practical to enforce all invariants for objects in the Aggregate and for the Aggregate as a whole in any state change. ”

Domain Driven Design User Group | April 2012 Goals of the Aggregate Pattern • Consistency Boundary – ‘Local consistency’ vs. system-wide • Enforce Invariants – Rules (“must be true”) – Increase the number of assumptions we can make about our system

Domain Driven Design User Group | April 2012 Coarse-Grained Aggregates • Modeling the entire “real world” • Optimistic Concurrency Issues • Performance / Scaling Implications

Domain Driven Design User Group | April 2012 Fine-Grained Aggregates • Model a smaller part of the world • Only a single Aggregate involved in a Transaction within each Bounded Context • Multi-Aggregate Consistency Solutions: – Redesign the model – Question Comprehension of Domain Knowledge – Consider Eventual Consistency

Domain Driven Design User Group | April 2012 Compound Entities and Value Objects • Prefer Value Objects to Entities • ‘Promote’ a Value Object to Entity only after careful consideration – More complexity – Persistence Challenges – Opportunities for Errors in code Aggregate Boundary Entity 1 Entity 2 Entity 3 Value. Object 1 Value. Object 2

Domain Driven Design User Group | April 2012 Multiple Aggregate References Aggregate Boundary Entity 1 Entity 2 Entity 3 c y eb ren e f Re ID Value. Object 1 Aggregate Boundary Value. Object 1 Entity 1 Value. Object 2 Value. Object 3 Value. Object 4 Reference by ID Value. Object 1 Value. Object 2

Domain Driven Design User Group | April 2012 Consistency of Multiple Aggregates • Aggregates only reference other Aggregates by their Root Entity – And even then, prefer a Value Object (representing a reference to the ID) rather than a reference to the Aggregate Root Entity itself • IMPORTANT: Referenced Aggregates do not enter the consistency boundary of the parent!

Domain Driven Design User Group | April 2012 Loading Referenced Aggregates • Use the ID of the referenced Aggregate to load it as needed – Inject Repository into the Aggregate – Use external service to ‘look up’ the needed referenced Aggregates as required • Consider: both of these strategies are effectively ‘manual lazy-loading’ of referenced Aggregates • Consider: if only IDs are kept, references may be easily passed across bounded contexts and system boundaries – Much easier than attempting to pass actual objects/entities

Domain Driven Design User Group | April 2012 Multi-Aggregate Consistency • Attempt ‘Cross. Aggregate’ consistency? • Eventual Consistency? – Domain Events – Pub-Sub Messaging Semantics • retry, resiliency, durability, compensating actions

Domain Driven Design User Group | April 2012 Transaction/Consistency Guidance • If its the responsibility of the user executing the action on the Aggregate to ensure consistency, prefer the ‘Cross-Aggregate Transaction’ approach • If its the responsibility of the system to ensure consistency, prefer the eventual-consistency approach

Domain Driven Design User Group | April 2012 Discussion • • • Viewpoints Experiences What Works? What Doesn’t? And Why?