The One Question To Haunt Everyone: What is a DDD Aggregate? - Thomas Ploch - DDD Europe 2022
Ғылым және технология
Domain-Driven Design Europe 2022
dddeurope.com - / ddd_eu - newsletter.dddeurope.com/ / domain-driven-design-e...
Organised by Aardling (aardling.eu/)
There is one question that I am getting asked at almost every conference or meetup: What is and what isn't an Aggregate? How do we design an Aggregate? To be honest, it's not an easy answer, even for experienced practitioners.
In this session I am summarizing the current state of affairs regarding Aggregate design in the Domain-Driven Design community.
I am Thomas, and I design systems for people and computers for fun and profit!
My career has navigated me through various industries like Finance & Insurance, Medical, Automotive and Travel. I have been wearing many differently shaped hats over the last 15 years. From System Administration, Test Automation, Web Development, Software Architecture & Design, Product Design & Organisation Design, I can draw on a bit of experience that currently helps me every day as a Principal Solutions Architect FlixBus.
The biggest realization over the last few years is that the most important component of success is not running the latest distributed architecture in the cloud, but to enable people to work smart to manifest their ideas in helpful products. I want to share my experiences and hope that you can take away a bit of knowledge that can help you later.
It is impossible to design useful software without understanding the underlying forces driven by market conditions, competitors, business strategy and the actual people using or building the software. Hence, I firmly believe that a wider definition of system design is required to achieve an adaptive and evolvable environment of people, processes and technology that can react to changing conditions in our fast paced digital world.
Пікірлер: 35
Great talk Thomas! Thanks DDD Europe for sharing!
What a wonderful explanation thanks
Best overview of aggregates and the reasoning behind it so far for me.
It's encapsulation (a Facade (AR) provides an interface to effect aggregate behaviors) & cohesion (the aggregate being a group of closely related coevolving objects) - it's just that it's applied beyond the level of a single object.
What an excellent talk, thank you very much for putting it out!
Brilliant lecture! Thank you.
awesome talk, very clear explanation thanks
Insightful Talk on just what Aggregates are, a Deep, Revealing Dive. Thank you so much.
Fantastic explanation, very useful talk.
IMO, a fundamental flaw that involves the DDD aggregate concept is that persistence concerns leak into their design - eg: race conditions because big object graphs, load to the database due to lots of entities, etc. This might lead to designs dictated because of your infrastructure components, not your domain.
@matthieujacquot8841
Жыл бұрын
I guess that, like all engineering problems, we've to accept that we live in the real world. This reminds me the "fallacies of distributed computing" : sure everything would be easier and nicer if the network was reliable, without latency... but it's just not true and we've to deal with it
@NaveenSiddareddy
Жыл бұрын
what if each entity has it local storage inside the aggregate and triggers another entity based on invariants (business rule)? essentially nodes and edges inside aggregate
Very engaging and informative presentation.
the quote may come from Vaughn Vernon paper "Effective Aggregate Design". I quote the paper : "Therefore, it is just plain smart to limit aggregate size. When you occasionally encounter a true consistency rule, then add another few entities, or possibly a collection, as necessary, but continue to push yourself to keep the overall size as small as possible"
@thomasgraf2107
8 ай бұрын
yes i had this paper in mind as well.
Thank you very much!
awesome!
Very well explained! But there is one question left! how aggregates communicate with each other? do they "just" reference each other, for simplicity in the same bounded context?
My opinion based on months of exploration trying to understand this topic. No offense intended... Q: "What does this picture represent? Why does it take 3 months to implement a small little change?" A: Tight coupling and low cohesion caused by incorrect boundaries. Suggesting that Aggregates, in and of themselves , can stop a system from spinning out of control is highly questionable. The boundaries need to be correct or coupling will take over. Everything will start breaking with even the most simple change, regardless of any Aggregate implementation. Of course, Aggregates, just like any other software construct, are "artificial" and "invented", but the proper boundaries most certainly are not. I really think that this is a misinterpretation of the blue book. Evans effectively said the opposite, "Forcing the required domain functionality to be the responsibility of an ENTITY or VALUE either distorts the definition of model-based object or adds meaningless artificial objects". Even in the cutlery metaphor, this becomes evident. Sure, cutlery is used together. So, keeping it in the same drawer (Aggregate) seems reasonable. However, the number of tines on a fork has absolutely nothing to do with knives or spoons. We have now coupled completely separate concerns and planted the seed for future disaster. Q: Why should Aggregates "be as small as possible" ? A: Because Vaughn Vernon said so! Q: OK, maybe, but why did he say that? Aggregates should be as small as possible because the immediate transactional consistency boundaries that they protect are relatively small by their very nature. "Finding correct service boundaries is really, really hard." - Udi Dahan paraphrase circa 21st century earth, local time.
if these things have to be explained the ddd book cant be so good
Awesome
composite: all functionality in one class. aggregate: functionality spread over multiple classes and one (facade) aggregating them. (mentioned in Ivar Jacobson‘s OOSE book 😁)
it seems like fancy OO
its fun to get there, but its not fun to be there never been more accurate!
what if you have huge data like 100000000comments in Post object. I don't think you can init a domain object with that much... looks useless to me when dealing with large chuncks of data. Thoughts?
@3:33 il problema non è se il system arriva o no a questo livello di complessità, il problema è chi scrive una query che implica 1000 tabelle...
@ornous
Жыл бұрын
True.
it seems like the rediscovery of hot water, e.g. the entity-relationship model.. is it more important to wear a cap with a visor and a floral shirt, or a fruit shirt with pears and oranges? ::
@NaveenSiddareddy
Жыл бұрын
everything in the world ends up as entity and relationships.. a graph with active nodes might solve this problem
@boltthrower142
Жыл бұрын
@@NaveenSiddareddy yes, I wonder if there's a real need for these ever new presumed "concepts", apart from selling books & colorful gadgets ;;
Lol, zero real solutions given. The first rule of distributed computing should be : don't do distributed computing (unless you really need to). Not "split your ACID boundaries early on" into various "agregates". For instance, this talk doesn't explain all the inconsistent system states that can occur if that UserAccount is deleted on one side, the CRMAccount should react to it and a third system losely depends on the existence of the CRMAccount. Like billing a user that shouldn't exist in your system anymore. Stuff like that. Without the saga patterns to monitor such inconsistencies and try repairing them, offering cancellation or refund. Premature distribution is a recipe for disaster. Agregates teached this way hence are a recipe for disaster.
@md.redwanhossain6288
Ай бұрын
Domain events can help here.
If you can't explain it to a six year old, you don't understand it yourself.
@andyliu1210
9 ай бұрын
And one should stop using fancy words (specialized terms)
@md.redwanhossain6288
Ай бұрын
So you want to teach DDD to a six year old? Good luck with that.