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 )