Chapter 1 - I am here to kill the aggregate

The aggregate has always been, for me, one of the most controversial and weakest elements of Domain Driven Design.

During my consultancy activity, I have been able to verify that the full understanding of the aggregate concept remains difficult for many. It is easy to make mistakes in the modeling phase, which will be very complex to fix in more advanced stages of development.

As a result, some developers feel that the whole architecture is excessively difficult and complicated.

I want to show you another world, where there is no aggregate. I am here to kill the aggregate.

For those unfamiliar with it, let me introduce it to you.

The Aggregate

Its definition is, in my opinion, is quite vague:

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

If you are confused by this definition, let's try to read what the blue book recommends for moving 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

Do these rules of thumb really help us build our own "instinct" for spotting aggregates in our domain?

I don't think so...

I'd like to present a practical example, to better understand the pitfalls of the aggregate.

I found 5 main criticalities of the aggregate, that I matched with 5 villains from Kill Bill movies.

Let's simulate a simple modeling exercise using Event Storming. The domain is the educational domain. The rules are the following:

1. A course cannot accept more than N students
2. N, the Course Capacity, can change at 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)

First, let's identify the events.

After the course has been created, it may happen that a student subscribes to the course, or unsubscribes. Course capacity may be updated from time to time.

Let us now analyze the trigger of these events. In our example, all these events are triggered by commands sent by the user.

So far, so good.

The story continues to the next chapter
Chapter 2 - The Aggregate does not fit the storytelling

... or watch the full story on youtube