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!
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
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.
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
This is the clearest explanation of DDD I've ever come across. Thanks a lot!
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!
I can't believe how clearly this video explains everything. It's the best comprehensive explanation I've had in a while.
This is the best and easiest explanation of DDD !!!! Thanks a lot.
This channel clearly deserves way more subscribers. Thank you and keep on the good work!
Thank you so much for the simple easy to understand explanation of DDD😭
The clearest and simplest explanation I have come across! Thanks!
an undervalued video with amazing explanation of so sophisticated topic.
мое почтение
By far the best description of DDD.
These videos are a lifesaver! Keep making them!
Simply amazing.. thanks for this. I wish these came once every other day :). They are really that good.👏💪
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!!!
Wow, it's not even 8 months from the last video. Nice :)
That was so easy and quick!
Beauuutiful explanations! Thanks a lot
This is also somewhat i figured. Thanks for clarifying everything 👌
great explanation! Thank you
Really well explained. Well done!
Please continue this domain driven design series
Please, continue doing this amazing content
Nice video ! I'm sure that authorization code flow or some another security flows will be very helpful :)
Great content! Keep going👍
LOVE THIS!!! Please make more videos
brilliant content
Very Good
insane explanation thanks alot
I love how the purple 🟣 is keep here in the car aggregate 😂
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.... 😅
Nice new upload, please keep it up
Glad you're enjoying them!
well explained
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 :)
thank you very much.
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.
Which book is good for DDD, I want to be good in DDD suggest me some good source
Keep it up.
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.
perfect
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