Just thank you. Really, thank you for the great explanation. You put a lot of work into it, and it's worthy of respect. You are cool, I will be very happy to watch more videos about DDD from you.
It all depends on the context of your problem. A common example I like to use to explain these is money. Value Object: Value objects are void of identity, and are all about measuring and quantifying things. If you have $5, you don't care which five dollar bill you have in relation to all the five dollar bills in circulation, just the fact that you have $5. Entities: Now consider money within the context of the government responsible for creating the actual dollar bills. Each five dollar bill has an identity within this context as we're interested in tracking all the five dollar bills created and create a unique serial printed on each bill. We would treat money as an entity because money has an identity in this scenario. Aggregates: Aggregates are a cluster of related objects that we treat as a unit for the purpose of data changes. Aggregates are also responsible for enforcing invariants, which are conditions that must be true before performing an action. Aggregate root: The aggregate root is the entity you choose within your aggregate to be the entry point of your aggregate. Other objects within your domain can hold references to only the aggregate root and not the internal entitles. All actions that need to be taken against your aggregate must happen through the aggregate root. Consider an example of Money, Accounts and Bank objects and you want to perform a $100 withdrawal. We could create an aggregate with these three objects with the Bank object being the aggregate root. That means you would perform your withdrawal through the bank object. The aggregate would then enforce the invariants, perhaps checking your account if you have enough money to perform the withdrawal. And if you do, it would dispense the money and appropriately reduce your account. The key thing to note here is the interactions with the account and money objects are internal to the aggregate and you're accessing the aggregate through the bank aggregate root. Hope this helps clear things up for you.
Your thumbnails are very bad. The reason being is if you look at UA-cam playlists they have black transparent rectangles to the right with white text. I almost did not click on this video because I thought it was a playlist and did not want to watch many videos on this subject.
Best ever explanation of Value Objects!
Thank you!
Just thank you. Really, thank you for the great explanation. You put a lot of work into it, and it's worthy of respect. You are cool, I will be very happy to watch more videos about DDD from you.
Thank you for the nice comment. I really appreciate it. I’m glad you enjoyed the video.
"I really hope you found some value inside this video" yes, Value Objects :D
Nicely explained. Great Video. Please make more videos on DDD.
Very well explained. I hope you continue creating content.
Vídeo incrível, adorei! Abraços do Brasil :)
Really helpful 👌
Brilliant videos!
Thank for awesome video!
Great content
Bro very very thanks for the video
Great video, it deserves more views ;)
Great vid! Also reading this Eric Evans book you mentioned and was confused at this part. Thank you for the clarification :)
I appreciate the nice comment and you’re welcome.
amazing
I finally got it! Thank you!
You’re welcome!
nice tx
You're welcome
Dude, well done!
Thank you. Glad you enjoyed it.
@@CodingConcepts Are you going to dive deeper into DDD and explain such things like Domain, Aggregator and so on?
@@worddoc4322 Yeah. The plan as of now is to run through more DDD concepts.
Thanks , Got clarified
You’re welcome
How does this relate to aggregates, aggregate roots and entities
It all depends on the context of your problem. A common example I like to use to explain these is money.
Value Object: Value objects are void of identity, and are all about measuring and quantifying things. If you have $5, you don't care which five dollar bill you have in relation to all the five dollar bills in circulation, just the fact that you have $5.
Entities: Now consider money within the context of the government responsible for creating the actual dollar bills. Each five dollar bill has an identity within this context as we're interested in tracking all the five dollar bills created and create a unique serial printed on each bill. We would treat money as an entity because money has an identity in this scenario.
Aggregates: Aggregates are a cluster of related objects that we treat as a unit for the purpose of data changes. Aggregates are also responsible for enforcing invariants, which are conditions that must be true before performing an action.
Aggregate root: The aggregate root is the entity you choose within your aggregate to be the entry point of your aggregate. Other objects within your domain can hold references to only the aggregate root and not the internal entitles. All actions that need to be taken against your aggregate must happen through the aggregate root.
Consider an example of Money, Accounts and Bank objects and you want to perform a $100 withdrawal. We could create an aggregate with these three objects with the Bank object being the aggregate root.
That means you would perform your withdrawal through the bank object. The aggregate would then enforce the invariants, perhaps checking your account if you have enough money to perform the withdrawal. And if you do, it would dispense the money and appropriately reduce your account.
The key thing to note here is the interactions with the account and money objects are internal to the aggregate and you're accessing the aggregate through the bank aggregate root.
Hope this helps clear things up for you.
Your thumbnails are very bad. The reason being is if you look at UA-cam playlists they have black transparent rectangles to the right with white text. I almost did not click on this video because I thought it was a playlist and did not want to watch many videos on this subject.
Thanks for the feedback.
Exactly what I was thinking.
I think, data oriented people trying to understand information.