Chapter 3 - The aggregate mixes technical and business aspects

continues from Chapter 2 - The Aggregate does not fit the story telling

......

Let me introduce villain number 2.

The aggregate mixes technical and business aspects.

For some reason, consciously or not, we try to bring together, in the aggregate, two different models:

1. the model to guarantee the invariants
2. our mental model of the domain concept

Although this may seem natural, often, these two models do not coincide. Strong consistency constraints do not always reside within the same business concept. It may happen that there are consistency constraints in the intermediate area between two or more business concepts.

For some people, this difference between the domain concept and the consistency boundary is crystal clear. I was positively impressed by the technique used by my friend Mauro Servienti to model the aggregates. He takes a reverse approach, first grouping data that share consistency constraints, bringing together information that changes together or whose change is dependent. Only later, after the groups have been identified, he tries to assign them a meaningful name.

However, this approach is not used by everyone. On the contrary, too often I have seen the aggregate modeling exercise reduced to looking for the names, the entities of our domain. Going beyond this naive approach, gaining a deeper understanding of the meaning of the aggregate, often requires time and experience.

Despite some initial difficulties, we managed to identify our first aggregate: the course.

It will be able to handle some types of commands and publish some types of events.

If we choose to use a model based on entities and value objects, we could represent the aggregate course in this way:

Please note that,  whenever the aggregate has to manage a student subscription or unsubscription command, then it makes use of its entire state to make the relative decisions. When instead it has to manage a command for updating its own capacity, it uses only part of the state.

Indeed, the invariant relative to the capacity update concerns only the current value of the capacity. Nothing else. There is no constraint related to the current number of subscriptions.

The same if we decide to use event sourcing. All events are important for handling the subscription and unsubscription commands. While just some events are important for handling the capacity update command.

The story continues to the next chapter
Chapter 4 - The larger the Aggregate, the greater the contention

... or watch the full story on youtube