Domain-Driven Aggregates Explained | Why you should use them

[@MarcoLenzo]

Do you use aggregates in your applications?

[@rcosta551]

Yes. I usually figure out them through event modeling

[@MarcoLenzo]

@@rcosta551 How do you go about event modeling? Do you use event storming?

[@artemvolsh387]

Your content is gold, complex topics, explained in a short amount of time with close to real scenario examples, that helps to understand the topic more deeply. Subscribed immediately!

[@MarcoLenzo]

Thank you very much! Such comments motivate me to produce more content 🙏

[@grantcrose26]

Marco, I just want to thank you for the effort that goes into these videos. The Evans and Vernon books are dense -- while these videos are not a replacement for those texts, they have really helped give me a foundation and basic understanding that I can bring into my study.

[@MarcoLenzo]

Thank you Grant 🙏 I totally agree about those books. My hope is to instill some curiosity in the audience by quoting a few key concepts.

[@midoevil7]

I was just thinking about layered architecture and service classes when you pointed it out 😅 That services essentially become the aggregate in layered architecture, but i think i need to check you video about why this is problematic. Anyway, great content! Especially the short video format.

[@MarcoLenzo]

Thank you! I don't think using services instead of aggregates is problematic per se. The main issue is whether you are creating appropriate boundaries around related classes in your domain to enforce consistency. In my experience, many developers create one service class per entity. Then, they let different services depend on each other and over time it becomes very messy. It is not possible anymore to predict the flow of calls, let alone preserve the consistency of the model. In those scenarios, formalizing the concept with aggregates might give teams the chance to think about this problem and define boundaries before they become aware of it because of some nasty bug 😝

[@midoevil7]

@@MarcoLenzo I think I understand what you mention here. Creating a service per entity basically makes them mostly a mapper between dto and corresponding entity which just complicate things. I usually use services because they play well with spring IoC layered architecture, but a service for me represents a unit of business logic. Interdependency between services can be messy indeed, but I can see the same happening in aggregates if some helper classes are used. I think as long as the hierarchy of services is preserved, meaning upper level logic is calling lower level ones, things can be managed and we reach the same point.

[@MarcoLenzo]

Totally agree!@@midoevil7

[@MrMal40]

Great video again. Thank you alot! ❤

[@MarcoLenzo]

Thank you! 🙏

[@zakichan-r8c]

What about a playlist to apply the ddd concept using java and spring boot. @Amichai Mantinband made one, but it's using microsoft...

[@MarcoLenzo]

Thank you for the idea

[@davidg1513]

why people dont use ddd is a mistery to me

[@MarcoLenzo]

Hope that no "functional bro" reads this! 😁 I think what concerns me the most is when we think we are using DDD but in reality we have no idea on what DDD is or, most importantly, what our actual approach is. 😅