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. 🙂

[Baasie]

My apologies for the slooow response – writing a book completely flushed my cognitive load! After this long, I should probably rewrite and add more info when I can find some time :D. There's a lot to unwrap here, so bear with me.

Okay, so there are some discrepancies about moving aggregate (not policy) to constraint. During a conversation with Alberto at the DDD Europe .. I think 2022, he mentioned that it might be better to call aggregates "legacy" after we talked about me using the word "constraint" like some others in the community. I know people at Aardling focus a lot more on constraint mapping during EventStorming, but I don't know the details.

I started using constraints many years ago because, when doing a lot of EventStorming with non-DDD'ers, I wasn't focusing on aggregates at all. That wasn't the most important part. I usually started with a process model and moved towards software design. But, actually, you could first call it "process design" because, first and foremost, we were designing the process. In that process, we wanted to capture business rules without giving it too much thought. So, I just started calling them constraints (since policies are also business rules) and that might have been influenced by Mathias and Aardling, but it's too long ago to remember...

The reason is that from these constraints, or business rules, you don't need to end up with aggregates, objects, or anything. I don't want to bias myself by using a design pattern at this point. After the software/process design is done, I usually do some CRC-card modeling. From there, I might cycle back and forth to the EventStorming and MAYBE start distilling Aggregates where needed.

So, based on me explaining my experience, I remember Alberto mentioning that "legacy" might be a better term, but the important part is the concept of 'the yellow thing' and we should adapt the naming of it to the context.

However, talking with him at the last DDD Europe, we had a conversation where he said perhaps keeping it might be okay. Aggregates sometimes pop up during software design, and that's okay. I must say, I can't remember both conversations with Alberto fully, so perhaps it's best to have a longer conversation about it next time I see him.

I hope this clears it up! I'm fully okay with providing more context to the cheat sheet. I'm curious about what you think of my explanation!

[ewolff]

Thanks. That makes a lot of sense and explains it very well, thank you again! 🙂
Maybe you want to explain the reasoning in the cheat sheet or some place else? I find it particularily interesting that you are saying "aggregate" as well as "constraint" might be useful - shouldn't you allow for both of it in the cheat sheet and other documents?

[mfheiss]

@Baasie
That was a really interesting read to start the week with :)
Thank you for taking time to write that response.

I'm not sure still if "deprecated" or "legacy" would be the right words for what has happened.
Besides both sharing the same sticky note color those concepts don't have that much in common and could also be used in combination (e.g. by introducing another color for the original aggregates if the discussion around those is valuable for attendees). They both can be used depending on which discussion and learning-outcome you want to create in those sessions.

The current statement kind of suggests that aggregates shall not be used any more (sounds like whoever does it, breaks important rules).

Maybe a short explanation / summary from this story could be written in the footnotes and the wording could change a little:
"The official color to use is a large yellow Post-it. In the early days of EventStorming, the yellow Post-it was used to define and discuss aggregates—a concept that was often difficult for business stakeholders to grasp. While discussing aggregates can be valuable in some contexts, most facilitators now prefer to focus on identifying constraints within the process. (See footnotes for more on the evolution of the yellow sticky note.)"

PS: The image-links are broken in the current eventstorming guide.
Looks like something happened to the links when changes to the website were made.

My apologies for the slooow response – writing a book completely flushed my cognitive load! After this long, I should probably rewrite and add more info when I can find some time :D. There's a lot to unwrap here, so bear with me.

Okay, so there are some discrepancies about moving aggregate (not policy) to constraint. During a conversation with Alberto at the DDD Europe .. I think 2022, he mentioned that it might be better to call aggregates "legacy" after we talked about me using the word "constraint" like some others in the community. I know people at Aardling focus a lot more on constraint mapping during EventStorming, but I don't know the details.

I started using constraints many years ago because, when doing a lot of EventStorming with non-DDD'ers, I wasn't focusing on aggregates at all. That wasn't the most important part. I usually started with a process model and moved towards software design. But, actually, you could first call it "process design" because, first and foremost, we were designing the process. In that process, we wanted to capture business rules without giving it too much thought. So, I just started calling them constraints (since policies are also business rules) and that might have been influenced by Mathias and Aardling, but it's too long ago to remember...

The reason is that from these constraints, or business rules, you don't need to end up with aggregates, objects, or anything. I don't want to bias myself by using a design pattern at this point. After the software/process design is done, I usually do some CRC-card modeling. From there, I might cycle back and forth to the EventStorming and MAYBE start distilling Aggregates where needed.

So, based on me explaining my experience, I remember Alberto mentioning that "legacy" might be a better term, but the important part is the concept of 'the yellow thing' and we should adapt the naming of it to the context.

However, talking with him at the last DDD Europe, we had a conversation where he said perhaps keeping it might be okay. Aggregates sometimes pop up during software design, and that's okay. I must say, I can't remember both conversations with Alberto fully, so perhaps it's best to have a longer conversation about it next time I see him.

I hope this clears it up! I'm fully okay with providing more context to the cheat sheet. I'm curious about what you think of my explanation!