NTCoding
commented
1 year ago 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 https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/issues/14, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFI67XUDS5WCSOH4JRBPJ3W5P2Q5ANCNFSM6AAAAAAWEZR5JA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
ewolff
vanto
kdmsnr
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. 🙂