Presented by Sara Pellegrini https://sara.event-thinking.io/ Hosted by Avanscoperta https://www.avanscoperta.it/en Streaming Video https://www.youtube.com/watch?v=DhhxKoOpJe0 L'aggregato ha sempre rappresentato per me uno degli elementi più controversi e deboli della teoria del DDD. La sua definizione risulta a mio parere estremamente vaga: "L'aggregato é un cluster di oggetti associati che devono essere trattati come una sola unità al fine di modificare i dati." Tentiamo di chiarire meglio il concetto: "L'aggregato costituisce l'unitá di consistenza del tuo dominio" Le cose non migliorano di molto... Durante la mia attività di consulenza, ho potuto verificare che la piena comprensione del concetto di aggregato rimane ostica per molti. E' facile commettere errori in fase di modellazione ai quali sará molto complesso porre rimedio in fasi piú avanzate dello sviluppo. Come conseguenza, una certa percentuale di sviluppatori si convince che l'intera architettura sia eccessivamente difficile e complicata. Il mio obiettivo é proprio quello di mostrarvi una via alternativa, nella quale l'aggregato non esiste.

2. @_sara_p_
Sara Pellegrini

4. The aggregate

5. The aggregate
An aggregate is a cluster of associated objects
that we treat as a unit for the purpose of data changes.
From blue book - Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans

6. The aggregate is ... confusing

7. From theory to practice
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
reference to the root only.
From blue book - Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans

8. Event Storming
Education domain
1) A course cannot accept more than N students
2) N, the Course Capacity, can change any time
to any positive integer different from the current one
(even if the number of currently subscribed students is larger than the new value)

9. Course
Created
Event
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Course
Capacity
Changed
Event
Create
Course
Command
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Update
Course
Capacity
Command
time

10. Story Telling
Storytelling is at the heart of human communication.
Storytelling does not require any special competence/skill.
It helps break down the barriers between technicians and business experts.

11. The aggregate is the boundary of consistency
When a change to any object with the aggregate boundary is committed, all
invariants of the whole aggregate must be satisfied.
From blue book

12. Course
Created
Event
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Course
Capacity
Changed
Event
Create
Course
Command
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Update
Course
Capacity
Command
Course
Course
Course Course
1) A course cannot accept more than N students
2) N, the Course Capacity, can change any time to any
positive integer different from the current one

13. Aggregate does not fit
with Story Telling

14. Aggregate does not fit with Story Telling
It is not naturally part of the story: the story teller is forced to add this element
Should business experts understand what a consistency boundary is?
Leads back to the old modelling-first/data centric approach.
Moves the focus from the behavior to the model.

15. Aggregate Mixes technical and
business aspects

16. The nouns become our aggregates
Course
Created
Event
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Course
Capacity
Changed
Event
Create
Course
Command
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Update
Course
Capacity
Command
Course
Course
Course Course

17. The course
Course
Create Course Command
Subscribe Student to Course
Command
Unsubscribe Student to Course
Command
Update Course Capacity
Command
Course Created
Event
Student Subscribed to Course
Event
Student Unsubscribed from
Course Event
Course Capacity Changed
Event

18. The COURSE
aggregate
<<Aggregate Root>>
Course Subscription
*

19. The COURSE
aggregate
<<Aggregate Root>>
Course Subscription
*
Subscribe Student to Course
Command
Unsubscribe Student to Course
Command

20. The COURSE
aggregate
<<Aggregate Root>>
Course Subscription
*
Subscribe Student to Course
Command
Unsubscribe Student to Course
Command
Update Course Capacity
Command

21. Event sourced COURSE aggregate
Course Created Event
Student Subscribed to Course
Event
Student Unsubscribed from
Course Event
Course Capacity Changed
Event
Subscribe Student to Course
Command
Unsubscribe Student to Course
Command
Update Course
Capacity Command

22. Event Storming of this problem:
Education domain
1) A course cannot accept more than N students
2) N, the Course Capacity, can change any time
to any positive integer different from the current one
(even if the number of currently subscribed students is larger than the new value)
3) The course title can change any time
to any title different from the current one

23. Course
Renamed
Event
Rename
Course
Command
Course

24. The larger the Aggregate
the greater the contention

25. The boundary of consistency
is also the boundary of concurrency

26. Concurrent command execution
Update Course
Capacity Command
Rename Course
Command
<<Aggregate Root>>
Course Subscription
*
<<Aggregate Root>>
Course Subscription
*

27. Alternative solution
<<Aggregate Root>>
Course Subscription
*

28. <<Aggregate Root>>
Course
Subscriptions
Subscription
*
Alternative solution: CourseInfo & CourseSubscription
<<Aggregate Root>>
Course
Info

29. Course
More contention
Simpler
CourseInfo & CourseSubscriptions
Less contention
Additional complexity
➔ Creation of multiple aggregates
➔ Synchronization

30. We did a modelling mistake…
Now what???
State Persisted Aggregates
- Script
Event Sourced Aggregates
- ???

31. Refactoring with Event Sourcing
Course
Created
….
Course
Renamed
Course
Capacity
Changed
….
Course
Capacity
Changed
…. ….
Course
Subscriptions
Created
….
Course
Renamed
Course
Capacity
Changed
….
Course
Capacity
Changed
…. ….
Course
Info
Created

32. Event Sourced Aggregates
Are Hard to Refactor

33. Event Storming of this problem:
Education domain
1) A course cannot accept more than N students
2) N, the Course Capacity, can change any time
to any positive integer different from the current one
(even if the number of currently subscribed students is larger than the new value)
3) The course title can change any time
to any title different from the current one
4) The student cannot join more than 10 courses

34. Create
Student
Command
Subscribe
Student to
Course
Command
Student
Created
Event
Student
Subscribed
to Course
Event
Unsubscribe
Student from
Course
Command
Student
Unsubscribed
from Course
Event
time

36. Course
Created
Event
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Course
Capacity
Changed
Event
Create
Course
Command
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Update
Course
Capacity
Command
Course
Course
Course Course

37. Create
Student
Command
Subscribe
Student to
Course
Command
Student
Created
Event
Student
Subscribed
to Course
Event
Unsubscribe
Student from
Course
Command
Student
Unsubscribed
from Course
Event
Student Student Student
4) The student cannot join more than 10 courses

38. Create Student
Command
Subscribe Student to
Course Command
Student Created
Event
Student Subscribed
Course Event
Student
Unsubscribe Student from
Course Command
Student Unsubscribed
from Course Event

39. The STUDENT aggregate
<<Aggregate Root>>
Student Subscription
*

40. Saga
We need some form of synchronization...
Subscribe Student to
Course Command
Subscribe Student to
Course Command
Subscribe Student to
Course Command
Student Subscribed
Course Event
Student Subscribed
Course Event
Student
Course
revert
Unsubscribe Student
to Course Command
Student Unsubscribed
Course Event
Student
1
1
2
3

41. Transactions that span
Multiple Aggregates
Could Cause
Unnecessary Complexity

42. It's just a long transaction...
Long transaction are very common when the business rule spans bounded contexts.
But when the rule spans multiple aggregates in the same bounded context?
Is this a necessary complexity or it can be avoided?

43. ● Does not fit the story telling
● Puts focus on model instead of behaviour
● Mixed technical and business aspects
● Can cause unnecessary contention
● Can cause unnecessary complexity
● Hard to refactor

44. Is there a better way to implement the command model?

45. Lets restart from… story telling
Decision Decision Decision
Decision Decision

46. Focus on the decision
Decision block = Message handler
The message handler knows what it needs to make a decision

47. Event sourcing
Event sourcing provides a huge advantage because it decouples
the persistence from the model needed for taking the decision
The message handler can build on the fly any model needed for
taking the decision starting from the correct event stream

48. Event sourcing
Course
Created
Student
Created
….
Course
Renamed
….
Course
Capacity
Changed
….
Update
Course
Capacity
Command
Decision based on the following
business rules:
● The course exists
● The new capacity is different from prev
Command Handler
Event store
Course
Capacity
Changed

49. Event Store
events = stream(AggregateIdentifier id)
events = stream(StreamQuery query)

50. Stream Query
{"StreamQuery": {
"DomainIdentifiers": [
{ "course": "7d9b35b6-b46a-43bf-8e4c-eb7e6c3a487d" }
], "Types": [
"CourseCreated",
"CourseCapacityChanged"]
}
}

51. The focus is on the Message Handler
Less waste of resources
No modelling phase
More flexibility

52. Concurrency
Update
Course
Capacity
Command
Rename
Course
Command
Course
Created
Student
Created
….
Course
Renamed
….
Course
Capacity
Changed
….
Course
Capacity
Changed
Course
Renamed
Decision based on the following
business rules:
● The course exists
● The new capacity is different from prev
Decision based on the following
business rules:
● The course exists
● The new name is different from prev one

53. Concurrency
Update
Course
Capacity
Command
Subscribe
Student to
Course
Command
Course
Created
Student
Created
….
Course
Renamed
….
Course
Capacity
Changed
….
Course
Capacity
Changed
Student
Subscribed
to Course
Decision based on the following
business rules:
● The course exists
● The new capacity is different from prev
Decision based on the following
business rules:
● The course exists
● The number of current subscription is
LOWER than the capacity (N)

54. Event Store
append(Event[] events)
append(Event[] events, StreamQuery query, EventIdentifier lastEvent)

55. Conditional append
if (lastEventIdentifier(query) != lastEvent) {
rejectAppend();
}

56. Warranty of consistency
The event(s) are appended only if the there is no other event matching the query
that has appended after the lastEvent

57. Concurrency
Update
Course
Capacity
Command
Subscribe
Student to
Course
Command
Course
Created
Student
Created
….
Course
Renamed
….
Course
Capacity
Changed
….
Course
Capacity
Changed
Student
Subscribed
to Course
Decision based on the following
business rules:
● The course exists
● The new capacity is different from prev
Decision based on the following
business rules:
● The course exists
● The number of current subscription is
LOWER than the capacity (N)
...592 ...593
append(event, query, ...592)
append(event, query, ...592)
...593 != ...592

58. Limited contention
Before the contention boundaries were those of the aggregate...
Now, the contention boundaries are those of the stream query

59. Does not seem very artificial?
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Course Course
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Student Student

60. Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Student
Subscribed
to Course
Student
Subscribed
to Course

61. From the story-telling perspective
Student
Subscribed
to Course
Event
Student
Unsubscribed
from Course
Event
Subscribe
Student to
Course
Command
Unsubscribe
Student to
Course
Command
Decision Decision

62. Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Student
Subscribed
to Course
Student
Subscribed
to Course
Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Student
Subscribed
to Course
Student
Subscribed
to Course
Pure Events
Course: jdsj4 Student:gfh3j ---
Course: jdsj4 Course: jdsj4
--- Course: jdsj4 Student: gfh3j
Tags (Domain Identifiers)

63. Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Student
Subscribed
to Course
Course: jdsj4 Student:gfh3j ---
Course: jdsj4 Course: jdsj4
---
Course: jdsj4
Student: gfh3j
Pure Events
Tags (Domain Identifiers)

64. Subscribe command
Student
Subscribed
to Course
Event
Subscribe
Student to
Course
Command
Decision based on the following business rules:
- A course cannot accept more than N students
- The student cannot join more than 10 courses

65. {"StreamQuery": {
"DomainIdentifiers": [
{ "course": "jdsj4..." },
{ "student": "gfh3..." }
], "Types": [
"Course Created",
"Student Created",
"Course Capacity Changed",
"Student Subscribed to Course",
"Student Unsubscribed from Course"]
}}

66. Student
Subscribed
to Course
Event
Subscribe
Student to
Course
Command
Decision based on the following business rules:
- A course cannot accept more than N students
- The student cannot join more than 10 courses
Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Course: jdsj4 Student:gfhl3 ---
Course: jdsj4 Course: jdsj4
---
Pure Events
Tags
(Domain
Identifiers)
Student
Subscribed
to Course
Course: jdsj4
Student: gfh3

67. Append Events with Domain Identifiers
append(DomainEvent[] events)
append(DomainEvent[] events, StreamQuery query, EventIdentifier lastEvent)

68. Domain Event
DomainEvent {
Event event,
DomainIdentifiers[] identifiers
}

69. Domain Identifier
KEY: VALUE
The concept in the domain The unique instance identifier
This is just an example,
They can be anything, as far as they are unique inside the bounded context

70. Student
Subscribed
to Course
Event
Subscribe
Student to
Course
Command
Decision based on the following business rules:
- A course cannot accept more than N students
- The student cannot join more than 10 courses
Course
Created
Student
Created
….
Course
Renamed
Course
Capacity
Changed
….
Course: jdsj4 Student:gfh3j ---
Course: jdsj4 Course: jdsj4
---
Pure Events
Tags
(Domain
Identifiers)
Student
Subscribed
to Course
Course: jdsj4
Student: gfh3j
Course
Fully
Booked
Event
Course
Fully
Booked
Course: jdsj4

71. append(DomainEvent[] events, StreamQuery query, EventIdentifier lastEvent)
[ Event event = Student subscribed to Course,
DomainIdentifiers[] identifiers = [{course: "jdsj4..."},
{student:"gfh3..."}],
Event event = Course Fully Booked,
DomainIdentifiers[] identifiers = [{course: "jdsj4..."}]
]
DomainIdentifiers: [ {course: "jdsj4..."},
{student:"gfh3..."}],
Types: [ "Course Created", "Student Created", "Course Capacity Changed",
"Student Subscribed to Course", "Student Unsubscribed from Course"]}
...593

72. Pure events
An event does NOT belong to an aggregate
An event is just a description of a fact that is important for the business
An event can be related to one or multiple domain concepts, addressed by their
Domain Identifiers

73. Less complexity
No owner of the event
The business decision can easily involve several domain concepts
The decision is taken in one place

74. Saga
Less synchronization needed
Subscribe Student to
Course Command
Student Subscribed
Course Event
Subscribe Student to
Course Command
Student Subscribed
Course Event
Course
revert
Unsubscribe Student
to Course Command
Student Unsubscribed
Course Event
Student
Subscribe Student to
Course Command
Student

75. More flexibility
Event sourcing provides a huge advantage because it decouples the persistence
from the model needed for taking the decision
Refactoring
● Change the StreamQuery
● Add/Remove Domain Identifiers

76. ● Perfect match with story telling
● Focus on behaviour instead of model
● Less contention
● Less complexity
● Simpler to refactor

77. @_sara_p_
Sara Pellegrini