Aggregates are legacy?

[ewolff]

The cheat sheet talks about constraints but not about aggregates. In the change history, aggregates are marked as "legacy". However, there is not reasoning given. Alberto's book dedicates a whole chapter to aggregates so this cheat sheet gives a different idea about event storming which is confusing. It would be great to give the reasoning to better understand why we shouldn't use aggregates any more. I am afraid "...since we prefer not to use the word aggregate with business stakeholders" doesn't really explain it.
The cheat sheet says constraint "was called an aggregate before". But it seems constraint is a different concept from aggregate. The cheat sheet says a "constraint is a restriction we have or need to design from our problem space when we want to perform a command/action". Aberto mentions "aggregates as state machines" and "what I am really looking for are units of consistent behavior" - so a unit that behave in a specific, consistent way similar (but not identical) to aggregates in DDD tactical design.
Adding some reasoning somewhere would be great. Aggregate was a confusing term because they are also part of tactical design and Alberto's chapter in it current form doesn't really explain what they are. So changing the concept is a great idea but more explanation would be great. 🙂

[NTCoding]

I know there are a lot of different opinions out there and I’m not sure a consensus will ever be reached. Depending on the audience, I use business entity or aggregate. I don’t quite understand constraint in this context so I can’t help with that part. Le jeu. 23 mars 2023 à 07:19, Eberhard Wolff ***@***.***> a écrit :

…

The cheat sheet talks about constraints but not about aggregates. In the change history, aggregates are marked as "legacy". However, there is not reasoning given. Alberto's book dedicates a whole chapter to aggregates so this cheat sheet gives a different idea about event storming which is confusing. It would be great to give the reasoning to better understand why we shouldn't use aggregates any more. I am afraid "...since we prefer not to use the word aggregate with business stakeholders" doesn't really explain it. The cheat sheet says constraint "was called an aggregate before". But it seems constraint is a different concept from aggregate. The cheat sheet says a "constraint is a restriction we have or need to design from our problem space when we want to perform a command/action". Aberto mentions "aggregates as state machines" and "what I am really looking for are units of consistent behavior" - so a unit that behave in a specific, consistent way similar (but not identical) to aggregates in DDD tactical design. Adding some reasoning somewhere would be great. Aggregate was a confusing term because they are also part of tactical design and Alberto's chapter in it current form doesn't really explain what they are. So changing the concept is a great idea but more explanation would be great. 🙂 — Reply to this email directly, view it on GitHub <#14>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFI67XUDS5WCSOH4JRBPJ3W5P2Q5ANCNFSM6AAAAAAWEZR5JA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ewolff]

Thanks. I don't think a consensus is needed - I am fine with different ways to do things. My problem really is that I don't understand how and why "policy" is meant to replace "aggregate" - it seems too different to me. So more explanation / reasoning would be great. 🙂

[vanto]

I'd like to second that. "Aggregate is now officially a legacy" sounds like the consensus was reached, and from now on, all others are doing it wrong when talking about aggregates.

[kdmsnr]

@Baasie I'd like to know the reason for rewriting from aggregate to constraint. ( Ref #12 )

[mfheiss]

Oh boy, that GitHub issue took me on a journey. :)

Here are some publicly available references that gave me some hints:

• How to explain Design Level Event Storming to your mother
• Demystifying Event Storming: Design Level, Identifying Aggregates (Part 3)

But I couldn't find "official" resources where the "change" itself and calling it "legacy" is discussed.

Here's what I learned (and hopefully didn't misinterpret too many things):

@ewolff
A policy is a hint for event-driven behavior within the business process and gives clues about how/why Events cause other actions. "Event A triggers Command B" or "Circumstance A triggers Command B".

A constraint is about defining business rules to decide if Command is allowed to be succesful and result in an Event based on pre-/postconditions and invariants that have to be implemented as part of the validation logic of the command.

Therefore the new "constraint yellow sticky" appears to be about gathering those fine-grained rules and maybe afterwards (optionally) finding names for a group of rules that belong to the same "thing"/"concept" (the former often coarse-grained aggregate discussion in Event Storming). It is basically describing the consistency boundary of a DDD aggregate(?).

If that's correct I think I get the reason behind this change... In many workshops I experienced that business people struggled with aggregates. Often they tried to use the same word/concept over the whole process and needed a lot of ideas/clues given by the facilitator to differentiate. Starting with those rules might make it easier to name/group those concepts afterwards. At the same time I noticed that ddd-aware engineers tried to discuss value objects and entities instead of "the business". The newer approach might prevent some of those issues from happening at the cost of fine-grained discussions about business logic for transactional boundaries.

Back to the wording in this cheat sheet
This cheat sheet is, in my opinion, the best publicly available, free, and easy-to-digest resource about EventStorming. The original framing of this change could benefit by a quote from Alberto Brandolini and a link to a proper explanation in order to be less divisive for people that were not aware of that change.
"It was called an aggregate before, which is now officially a legacy word in EventStorming, since we prefer not to use the word aggregate with business stakeholders." is a good hint, but it may be too simplified :)

Otherwise, it seems that "Aggregates" are now the pineapple on the pizza, while it appears to be just a switch from a higher-level concept like "Salami" to "several ingredients that can be combined to Salami."
Remember, Alberto calls EventStorming like a pizza. The paper roll and domain events are the base of your pizza, the dough, but you put your ingredients on top of it the way you like (as long as it isn’t pineapple 😉).

PS: I'm open to any corrections or insights if I've misunderstood something! :)

[ewolff]

@mfheiss Thanks a lot for investing the time and effort to look into this so deeply! Sounds quite logical to me. I’d be eager to hear whether this is close to the actual reasoning behind the change. 🙂