This presentation explores how to design aggregates in Domain-Driven Design (DDD) effectively. We begin with a foundational overview of what aggregates are and why they matter, followed by a closer look at aggregate roots and the common challenges faced when working with aggregates. We then outline practical design rules of thumb that help guide decision-making and ensure consistency across the domain model. To ground these concepts in practice, we walk through two real-world design scenarios, each with different requirements and complexities. For each case, we analyze the domain, discuss trade-offs, and design aggregates that align with the principles of DDD. By the end, you will have a clear understanding of how to apply theory to practice and make informed design choices when working with aggregates in your own projects.

1. 1
Designing DDD
Aggregates
Presenter:

2. 2
Table Of Contents
Introduction
What are Aggregates
Aggregate Root
Aggregate challenges
Design rules of thumb
Designing Aggregates

3. 3
Introduction
It is a tactical DDD pattern.
Aggregate design is one of the most challenging tactical
tasks.
Goal?
oTry understand what an aggregate is.
oLook at real world use-cases.
oTry to set some rules of thumb for aggregate design.
oTry to design aggregates.

4. 4
What are Aggregates
A cluster of entities and value objects
that forms a transactional unit
Could be thought as a set of data that
must be loaded and committed
altogether.
It’s a place where we enforce our
domain rules/invariants
Aggregates handle commands (write
part) of the system operations.

5. 5
Aggregate Root
The main entity within an
aggregate responsible for
maintaining its integrity.
Could be thought as the API
gateway for the aggregate that
all external communication
goes through

6. 6
Aggregate Challenges
Complex concept.
Extract & Discovering aggregates is hard.
Designing aggregates with the right boundary is a true pain
(Size & Performance tradeoffs).
Cross aggregate validation is one big challenge.

7. 7
Designing Rules of Thumb
Let invariants be your leads/clues for designing.
Design aggregates to be small as much as possible.
Don’t get fooled by unreal domain invariants.
Design your aggregates to handle state-changing actions (commands
only).
Entity lifecycle is a strong indication of aggregate boundaries.

8. 8
Designing Aggregates (E-commerce Order
1)
Design an e-commerce application order aggregatewhere a
user would be able to create an order, add, remove line
items, close, and place order.
Main Entities:
oOrder
oLineItem

9. 9
Designing Aggregates (E-commerce Order
1) Cont.
First Try: 2 separate aggregates for order and line item.
Justification:
oEach handle commands only
• Order: Create, Cancel, Place.
• LineItem: Add, Remove.
oNo domain invariants
oSmall aggregates

10. 10
Designing Aggregates (E-commerce Order
2)
Design an e-commerce application order aggregatewhere a user
would be able to create an order, add, remove line items, close, and
place order.
Main Entities:
o Order
o LineItem
Knowing that
o An order must not contain more than 5-line items at once.
o If the total price exceeds 100$, then 5% discount is applied.

11. 11
Designing Aggregates (E-commerce Order
2) Cont.
• First Try: 2 separate aggregates for order and line item.
• Challenges:
• How to enforce domain rules?
• Loading 2 aggregates at once
• Putting logic into domain service
• Concurrency
• Bad design smells:
• Unable to enforce domain rules purely.
• An entity (LineItem) is trying to know about other entities of same type.

12. 12
Designing Aggregates (E-commerce Order
2) Cont.

Second Try: single aggregate for order and line item.

Justification
o The design enforced the 2 domain invariants
o Aggregate gets loaded/committed as single unit
o We can apply discount & line-items count check with this
design.

Considerations:
o Performance
o Size
o Purity
o Completeness

13. 13
Designing Aggregates (Ticket Aggregate 1)
You are required to design a Ticket aggregate in a project
management application, where a user can create ticket,
control its status (moving it to InProgress, Test, Done) and
close ticket.
Users are able to add comments in the ticket.
Main entities:
oTicket
oComment

14. 14
Designing Aggregates (Ticket Aggregate 1)
Cont.
First Try: 2 separate aggregates for Ticket and Comment.
Justification
oEach handle commands only
• Ticket: Create, Close, Move to InProgress, Test ...
• Comment: Edit, Delete.
oNo specific invariants to design it differently
oSmall aggregates

15. 15
Designing Aggregates (Ticket Aggregate 1)
Cont.
Argument #1: If a ticket gets deleted, all related comments must be
deleted so the comment entity should be an entity part of the ticket
aggregate due to this domain invariant.
Answer:
o That’s unreal-domain invariant, it’s instinctively obvious that we must
delete related comments when a ticket gets deleted.
o What we are seeing here is actually a relationship between entities than
a true invariant/behavior; and it’s very important to not overemphasize
entities relationships in DDD since we are modeling behaviors.
o A solution could be easily applied by emitting an event about a ticket
being deleted, and asynchronously we can delete related comments.

16. 16
Designing Aggregates (Ticket Aggregate 1)
Cont.
Argument #2: There is a domain
invariant that says, if the ticket was
archived, then no comments should
be added, so the comment must be
part of the ticket aggregate.
Answer:
o This could be a real-domain invariant
but mostly not.
o Simply, we can put the factory method
of creating comments in the ticket
aggregate.

17. 17
Designing Aggregates (Ticket Aggregate 2)
You are required to design a Ticket aggregate in a project
management application, where a user can create ticket, control its
status (moving it to InProgress, Test, Done) and close ticket.
Users are also able to add comments in the ticket.
Main entities:
o Ticket
o Comment
Knowing that
o No more than 10 comments must be added to a single ticket.

18. 18
Designing Aggregates (Ticket Aggregate 2)
Cont.
• First Try: 2 separate aggregates for order and line item.
• Challenges:
• How to enforce domain rules?
• Loading 2 aggregates at once
• Putting logic into domain service
• Concurrency
• Bad design smells:
• Unable to enforce domain rules purely.
• An entity (Comment) is trying to know about other entities of same type.

19. 19
Designing Aggregates (Ticket Aggregate 2)
Cont.
Second Try: single aggregate that combines ticket and comment.
Justification
o The design enforced the domain invariant.
o Aggregate gets loaded/committed as single unit.
o With this design, we can do the comments count check.
Considerations
o Performance
o Size
o Purity
o Completeness
This is a good design and in some contexts it’s perfect, but let’s squeeze
our minds and explore more options.

20. 20
Designing Aggregates (Ticket Aggregate 2)
Cont.
• Third Try: 2 separate aggregates for Ticket and Comment, but
with a counter field to track total comments on ticket
aggregate.
• This implies an eventual consistent solution:
a. Ticket aggregate enforces the count invariant;
if success, it emits CommentAdditionRequested
event.
b. A handler will asynchronously listen for
this emitted event and will respond by creating
the comment.

21. 21
Designing
Aggregates (Ticket
Aggregate 2) Cont.

22. 22
Designing
Aggregates (Ticket
Aggregate 2) Cont.

23. 23
Designing
Aggregates (Ticket
Aggregate 2) Cont.

24. 24
Designing
Aggregates (Ticket
Aggregate 2) Cont.

25. 25
Conclusions
Aggregates should not necessarily represent something meaningful to real life
or common sense, as long as they are enforcing and fulfilling domain rules, then
that’s fine.
There are no deterministic rules to always follow when designing aggregates.
It’s about balancing trade-offs.
Designing aggregates is being more of an art instead of a deterministic
approach.
PRACTICE MAKES PERFECT.

26. 26
Thank You!
Presenter: Maysam Mousa