The One Question To Haunt Everyone: What is a DDD Aggregate? - Thomas Ploch - DDD Europe 2022

  Рет қаралды 46,457

Domain-Driven Design Europe

Domain-Driven Design Europe

Күн бұрын

Пікірлер
@filipmilovanovic8942
@filipmilovanovic8942 Жыл бұрын
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.
@DevOpsCraftsman
@DevOpsCraftsman Жыл бұрын
Best overview of aggregates and the reasoning behind it so far for me.
@rammehar5531
@rammehar5531 Жыл бұрын
What a wonderful explanation thanks
@toinbis
@toinbis Жыл бұрын
Great talk Thomas! Thanks DDD Europe for sharing!
@Felipe-53
@Felipe-53 9 ай бұрын
What an excellent talk, thank you very much for putting it out!
@jorgeolive9605
@jorgeolive9605 Жыл бұрын
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.
@matthieujacquot
@matthieujacquot Жыл бұрын
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
@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
@joachimdietl6737
@joachimdietl6737 Жыл бұрын
if these things have to be explained the ddd book cant be so good
@matthieujacquot
@matthieujacquot Жыл бұрын
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
@thomasgraf2107 Жыл бұрын
yes i had this paper in mind as well.
@sotsch9280
@sotsch9280 Жыл бұрын
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?
@mohamedbeyremmakhlouf
@mohamedbeyremmakhlouf Жыл бұрын
awesome talk, very clear explanation thanks
@charlesopuoro5295
@charlesopuoro5295 Жыл бұрын
Insightful Talk on just what Aggregates are, a Deep, Revealing Dive. Thank you so much.
@boltthrower142
@boltthrower142 Жыл бұрын
@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
@ornous Жыл бұрын
True.
@igorpronin9484
@igorpronin9484 3 ай бұрын
Great talk and few examples.
@jelenacupac7
@jelenacupac7 Жыл бұрын
Very engaging and informative presentation.
@KangoV
@KangoV 2 ай бұрын
Is it still ok to pass a "guarded" entity out? I'm actually creating a class which encapsulates "wraps" the entities. These wrappers "guard".
@ANTGPRO
@ANTGPRO Жыл бұрын
Brilliant lecture! Thank you.
@pavelvasianovych4030
@pavelvasianovych4030 Жыл бұрын
Thank you very much!
@vincentcifello4435
@vincentcifello4435 Жыл бұрын
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.
@ismailm123
@ismailm123 Жыл бұрын
Fantastic explanation, very useful talk.
@sighupcmd
@sighupcmd 5 ай бұрын
I heard so many people struggling with Aggregate term, but all I see is just a classic GoF Facade done right.
@m13v2
@m13v2 Жыл бұрын
composite: all functionality in one class. aggregate: functionality spread over multiple classes and one (facade) aggregating them. (mentioned in Ivar Jacobson‘s OOSE book 😁)
@Deepz007
@Deepz007 Жыл бұрын
awesome!
@toufikoran8416
@toufikoran8416 Жыл бұрын
it seems like fancy OO
@botyironcastle
@botyironcastle 7 ай бұрын
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?
@shimadabr
@shimadabr 3 ай бұрын
They probably should be lazy loaded. Also, an update or create operation on the comment would probably involve searching the database for the entry (through the post repository) and creating/updating it accordingly. I'm not 100% sure though, I've started learning DD recently.
@ehm-wg8pd
@ehm-wg8pd Жыл бұрын
its fun to get there, but its not fun to be there never been more accurate!
@nasamind
@nasamind Жыл бұрын
Awesome
@boltthrower142
@boltthrower142 Жыл бұрын
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
@NaveenSiddareddy Жыл бұрын
everything in the world ends up as entity and relationships.. a graph with active nodes might solve this problem
@boltthrower142
@boltthrower142 Жыл бұрын
@@NaveenSiddareddy yes, I wonder if there's a real need for these ever new presumed "concepts", apart from selling books & colorful gadgets ;;
@kboite
@kboite Жыл бұрын
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
@md.redwanhossain6288 7 ай бұрын
Domain events can help here.
@McRakns
@McRakns 5 ай бұрын
Very long way to explain plain old encapsulation of the object-oriented design
@goblin29
@goblin29 26 күн бұрын
2 dakikada anlatılacak şeyi çok özelmiş gibi anlatmasak keşke...
@allmhuran
@allmhuran 5 ай бұрын
The idea that you can have two aggregates whose values are all identical other than some specific identity value, which makes them different, is fundamentally incorrect. The "specific identity value" *does not exist in the world*. It is *not part of the domain*. It's completely artificial, and therefore represents nothing. From the point of view of the domain, or any actual user who is using the system, two aggregates whose values are all identical are the same aggregate, by definition. To take a simple example, suppose I have a domain object representing a customer, and this customer happens to only have a single property - name. I create a customer "John". I then create another customer "John". How many customers do I have? ONE. You need proof? Suppose a customer calls up. You want to find them in the system. You ask them "what's your name". "John", they reply. Cool. Which "John" is THIS "John"? What are you going to do, say something like "Hey I have two Johns, one is ID 123 and the other is ID 124, which one are you?". The guy on the phone is going to ask what the heck you are talking about. This is the same mistake as saying "you don't need natural keys in your relational database, just add surrogate keys to your tables". No, that's completely and fundamentally wrong.
@davidbrandt1661
@davidbrandt1661 3 ай бұрын
I think you are missing some context. For random generated identity values (like data base keys) I would agree. In DDD however the identity of the aggregate (or an entity) should exist in the real world and should be a part of my domain. It is what sets them apart inside of the bounded context. It could be an unique identifier like a serial number, a customer ID, or a social security number.
@chavdarangelov1433
@chavdarangelov1433 Жыл бұрын
If you can't explain it to a six year old, you don't understand it yourself.
@andyliu1210
@andyliu1210 Жыл бұрын
And one should stop using fancy words (specialized terms)
@md.redwanhossain6288
@md.redwanhossain6288 7 ай бұрын
So you want to teach DDD to a six year old? Good luck with that.
The DDD Starter Modelling Process - Maxime Sanglan-Charlier - DDD Europe 2022
48:26
Domain-Driven Design Europe
Рет қаралды 24 М.
A Daily Practice of Empirical Software Design - Kent Beck - DDD Europe 2023
59:14
Domain-Driven Design Europe
Рет қаралды 36 М.
СИНИЙ ИНЕЙ УЖЕ ВЫШЕЛ!❄️
01:01
DO$HIK
Рет қаралды 3,3 МЛН
Cheerleader Transformation That Left Everyone Speechless! #shorts
00:27
Fabiosa Best Lifehacks
Рет қаралды 16 МЛН
It works #beatbox #tiktok
00:34
BeatboxJCOP
Рет қаралды 41 МЛН
Introduction to Context Mapping - Michael Plöd - DDD Europe 2022
59:15
Domain-Driven Design Europe
Рет қаралды 23 М.
What is DDD - Eric Evans - DDD Europe 2019
57:06
Domain-Driven Design Europe
Рет қаралды 267 М.
How to design great Aggregate Roots in Domain-Driven Design
11:30
Milan Jovanović
Рет қаралды 16 М.
Bounded Contexts - Eric Evans - DDD Europe 2020
34:02
Domain-Driven Design Europe
Рет қаралды 79 М.
The Intersection of Architecture and Implementation - Mark Richards - DDD Europe
58:24
Domain-Driven Design Europe
Рет қаралды 7 М.
Domain-Driven Design: The Last Explanation You'll Ever Need
21:05
Software Developer Diaries
Рет қаралды 14 М.
Mastering DDD Aggregate Modeling With THESE 3 Steps
17:26
Codewrinkles
Рет қаралды 11 М.
СИНИЙ ИНЕЙ УЖЕ ВЫШЕЛ!❄️
01:01
DO$HIK
Рет қаралды 3,3 МЛН