DDD Building Blocks
HTML-код
- Опубликовано: 30 июл 2024
- Explaining Aggregate Roots, Domain Events, Entities, Value Objects and Repositories - the building blocks in Domain-Driven Design.
0:00 Building Blocks
0:18 Ubiquitous Language
0:54 Value Objects
1:41 Entities
2:22 Domain Events
2:51 Aggregates
3:39 Repositories 
Наука
This is the clearest explanation of DDD I've ever come across. Thanks a lot!
I can't believe how clearly this video explains everything. It's the best comprehensive explanation I've had in a while.
Finally a clear and to the point explanation about DDD with concrete example. I learned a lot more under 5 mins than i did watching those vague abstract one hour conferences. Thank you for this!
Thats true. I thought the same way.
This is the best video explaining ddd terminology i've ever watcher. Thank you!
This channel clearly deserves way more subscribers. Thank you and keep on the good work!
These videos are a lifesaver! Keep making them!
Holy crap… this was a great explanation. Really good job! Love the analogies and simple examples with the nice animations and drawings! Keep it up!
This is a GREAT explanation of DDD, and tbh one of the best I've seen. I've subscribed to your channel, that's how much I like it!!!
The clearest and simplest explanation I have come across! Thanks!
This is the best and easiest explanation of DDD !!!! Thanks a lot.
By far the best description of DDD.
Simply amazing.. thanks for this. I wish these came once every other day :). They are really that good.👏💪
an undervalued video with amazing explanation of so sophisticated topic.
мое почтение
This is also somewhat i figured. Thanks for clarifying everything 👌
Really well explained. Well done!
Please, continue doing this amazing content
Nice video ! I'm sure that authorization code flow or some another security flows will be very helpful :)
LOVE THIS!!! Please make more videos
That was so easy and quick!
Great content! Keep going👍
Wow, it's not even 8 months from the last video. Nice :)
insane explanation thanks alot
thank you very much.
Please continue this domain driven design series
brilliant content
well explained
Keep it up.
perfect
Nice new upload, please keep it up
Glad you're enjoying them!
Which book is good for DDD, I want to be good in DDD suggest me some good source
It is very well explained, but I'm missing domain services. Quoting Evans: "Sometimes, it just isn’t a thing.".
Thanks! Aaaah yes - I'll add that to my list of potential future videos :)
Can't i perform atomic operation 'steal wheels' on car aggregate and save state? Seems like i could which would lead to the same problem which it supposedly guards against
If that's a valid operation in your domain then, sure, build it into the aggregate! But now I'm worried about what domain you're modelling.... 😅
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 chunks of data. Thoughts?
That's a great example. There's a bit of an art to defining the aggregate boundary, and I think yes you want to try keep them smaller than that.
Does your domain need the full comments list to be consistent? If two users load the page, then both leave a comment, should the second comment fail with some concurrency error? Or just allow both comments? Perhaps the boundary is around the comment, not the post.
But if you do, your implementation doesn't have to load every comment into memory to know if something has changed. Checking a LastCommentDate or LastUpdateDate could also work.
Isn't Value Object a bit of an oxymoron, since objects usually have identity in OO? My brain wants to call them Value Types. They behave more like value types such as int and enum, and I also think they are easier to implement as structs rather than classes in C#.
One reason to call them value OBJECT instead of TYPE, is that it is like an attribute of an entity. These attributes can also be simple or complex (=> object) but the important thing as the video also says is that it has to be immutable. For sure, simple attributes could be handled in structs or enums but the more complex it gets, the easier it is to implement it in a class. And in OO an object can literally be anything, either simple or complex. It is not a usual thing to have id in an object, thats more like an entity.
The aggregate looks like Facade for me
This is great insight. They are similar. The GoF facade tries to hide away all the inner objects though, whereas an aggregate root is just the node that we use to access the aggregate. You could design it so you load the full Car aggregate then access one of its Wheel objects to pump up a tyre. We just can’t load that Wheel directly from a repository using just its WheelId
In education contents pls avoid background musics. Its very annoying and disturbing to concentrate
I don't find that.
For me it's the opposite