Chapter 6 - The aggregate could cause unnecessary complexity
continues from Chapter 5 - Event sourced aggregates are hard to refactor
Let's add a little more spice to our example, introducing rule number 4:
- A course cannot accept more than N students
- 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)
- The course title can change at any time to any title different from the current one
- The student cannot join more than 10 courses
Back to the board! We need a new event for the creation of the student, and the relative command.
But here, things get complicated, since we need a new event for the subscription and a new event for the unsubscription. Both triggered by their respective commands.
Déjà-vu? Yes, because we have already met very similar events and commands when we were talking about the course.
The main aspect underlying the idea of the aggregate is the concept of boundary.
The boundary of consistency. The boundary of the complexity.
One of the purposes of the aggregate is precisely to contain the complexity, defining small bubbles isolated from each other, to have a minimal context where it is easy to make decisions.
This concept is perfectly in line with the best practices of decoupling and high cohesion. The intention is good, but it implies greater complexity whenever a constraint spans more than one aggregate.
- Does not fit the storytelling
- Puts focus on the model instead of behavior
- Mixes technical and business aspects
- Can cause unnecessary contention
- Can cause unnecessary complexity
- Hard to refactor
It remains only to shoot it down.The story continues to the next chapter
Chapter 7 - Focus on the behavior