Chapter 2 - The Aggregate does not fit the storytelling

continues from  Chapter 1 - I am here to kill the aggregate

......

One of the most powerful elements of DDD is that it has broken down the barriers between technicians and domain experts, thanks to tools capable of exploiting the immense potential of storytelling, first of all Event Storming.

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

In my experience, the usage of storytelling ensures an exceptional fluidity in the domain discovery process, but it hits a snag when we try to introduce the aggregate into the story.

Indeed, by definition, the aggregate is the boundary of consistency. The aggregate is the component responsible for ensuring strong consistency constraints within an ecosystem that is, by nature, eventually consistent. But, at the same time, it tries to represent the business entity acting as the guardian of a set of business rules. 

It is complex to explain to business experts what it really represents.

Obviously, we cannot provide business experts with a technical explanation of the aggregate.

However I need to admit that, to design the aggregate, I always start grouping together all data that shares consistency constraints.

In our example, the rules were related to the course. That's why I'd choose the Course as an aggregate.

Translating this idea into non-technical terms to explain it to business experts is not trivial. We can use metaphors, by asking questions like this:

• Who guarantees me that this rule will not be violated?
• In which box would you put this information?
  
• Who would you address this command to?

These tricks are not always effective. So here is the first bad guy in our story.

The Aggregate does not fit the storytelling

The introduction of the aggregate in storytelling breaks the fluidity of the discovery process.

It is an element that does not emerge naturally from the story; the story teller is forced to talk about it.

Business experts should absolutely not worry about understanding the technical aspects of our architecture. Nevertheless, they are somehow asked to identify precisely these elements, technical by definition.

Besides, the aggregate leads back to the old modelling-first/data centric approach. It moves the focus from the behavior to the model.

The story continues to the next chapter
Chapter 3 - The aggregate mixes technical and business aspects

... or watch the full story on youtube