Thank you soo much for wonderful explanation of Aggregate. I strongly believed that domain layer is very important in backend engineering because small projects also starts to grow and turn into real pain. once again thank you soo much I really enjoy you content.
Well explained! One question that leads into another tutorial I supposed (you may be covering it first video i've watched). Is when you clear employees, the employees would be in another bounded context and would need an event raised that they were "off" the project. That would lead into how you communicate between bounded contexts :) Then in the other bounded context they would be flagged as "available" and could be selected to be added to another project. :)
Great overview! I would wrap the collection in an IReadOnlyCollection in order to state the intention and make it harder for consumers to cast to list.
Awesome information with nice examples, it gave me more knowledges how correct to use DDD and deep understating of this. Hope you'll continue to provide similar tutorials about DDD further . Thank a lot!
Glad it was helpful! Videos on DDD will be a major part of this channel for the next couple of months. Make sure to check the DDD fundamentals playlist, as there are already videos on bounded contexts, entities, value objects and so on.
Hi @Codewrinkles, at the end of the video when you complete the project, you are talking about injecting DateTime service in order to get DateTime.Now, however this contradicts with ddd/clean architecture as it would introduce dependency on external shared (would it be part of the Kernel project?) service, how would you go about this while maintaining clean domain model? Thanks, super useful and comprehensive video like the previous 2 from your ddd series.
Maybe I was not clear enough. You'll never inject a service in an aggregate! If you're using a IDateTimeService then the Application layer would use that service to generate a datetime and it will pass it to the aggregate, either in the static factory method or in the constructor, depending on which way you choose to instantiate your aggregates.
Thanks for the good explanation but I am confused about ddd is it some approaches and patterns that I can implement some of it on need or it should be implemented all
DDD, as described initially by Eric Evans, comes with a lot of strategic and tactical design patterns. Some of them can be indeed adapted to non-DDD apps, but the more strategic ones that can't be adapted don't actually have to do only with code. It's also about team composition, ways of working and so on.
Great video keep it up!. I have one question After the CompleteProject() called what if we want to maintain members for future reference how we gone handle such scenarios.
Hello thanks for your efforts i have a little bit confused I will explain by an example if I have a room and this room has a Furnitures If I need to change the Furnitures of the room I should check some rules in the room. so, the room and Furnitures have a relationship so the room will be aggregate root and the Furnitures will be only entity but in the same time if I removed Furnitures that not mean that I need to remove the room so in this case there will be root aggregates so what is the correct
Persistence is always tricky when it comes to DDD. also for value objects in general. I will create dedicated videos covering persistence strategies when using DDD.
I am beginning to wonder if it is even possible to implement Aggregates according to the stated rules. Perhaps Mauro Servienti was correct "All Our Aggregates Are Wrong". Please help me understand this. Either Employee is an Aggregate or it is not. If Employee is an Aggregate, then it should only be referenced by Id within the Project Aggregate. In this case, including Employee Entities in the Transactional Boundary of Project violates the most basic principles of Aggregate design. An Aggregate Root (Project) should be wholly responsible for managing the state of a contained entity. If Employee is its own Aggregate, then it can be modified outside the Transactional Boundary of its supposed Aggregate Root (ie Project). If Employee is not an Aggregate, the situation here is perhaps worse. Project, the Aggregate Root, should completely manage the state of Employee objects. In fact, Project consumers shouldn't even know that Employee objects exist (just as Order consumers should not even know OrderLineItem exists). Currently, Employee objects are required to be instantiated outside of Project and passed in via a method. Calling this "full encapsulation" seems odd to me. I really don't mean to be critical. I have yet to see an example, outside of the canonical Order/OrderLineItem, that actually adheres to the rules of Aggregate Design, as stated. Please explain if I am incorrect as I really want to understand this.
Well, there's a reason why this video is part of a series. The next video on the series answers your question. Please watch them all as a lot of things might get clearer: th-cam.com/video/E2ctgrKhqBw/w-d-xo.html As a final word, DDD is complex and hard. That's why it only makes sense in very complex applications/domains where you'd probably have a microservices setup. For most other scenarios.
Well, the goal of the videos in this playlist is not to convince anybody about anything. It's just setting the DDD fundamentals. Some might find it useful.
yay finally understood aggregates. ty for the amazing content
Thank you soo much for wonderful explanation of Aggregate. I strongly believed that domain layer is very important in backend engineering because small projects also starts to grow and turn into real pain.
once again thank you soo much I really enjoy you content.
Well explained! One question that leads into another tutorial I supposed (you may be covering it first video i've watched). Is when you clear employees, the employees would be in another bounded context and would need an event raised that they were "off" the project. That would lead into how you communicate between bounded contexts :) Then in the other bounded context they would be flagged as "available" and could be selected to be added to another project. :)
This channel became one of my favourites one. Keep up the good work bro, excellent job!
Thanks, will do!
Great overview! I would wrap the collection in an IReadOnlyCollection in order to state the intention and make it harder for consumers to cast to list.
Sure, that's also a great idea. Probably even better!
Awesome information with nice examples, it gave me more knowledges how correct to use DDD and deep understating of this. Hope you'll continue to provide similar tutorials about DDD further . Thank a lot!
Glad it was helpful! Videos on DDD will be a major part of this channel for the next couple of months. Make sure to check the DDD fundamentals playlist, as there are already videos on bounded contexts, entities, value objects and so on.
This channel is amazing, good job!
Thank you for the kind words. I'm glad you found it. Make sure you also let others know wbout this channel.
Nice video!
Nicely explained video, thanks a lot
Glad it was helpful!
Hi @Codewrinkles, at the end of the video when you complete the project, you are talking about injecting DateTime service in order to get DateTime.Now, however this contradicts with ddd/clean architecture as it would introduce dependency on external shared (would it be part of the Kernel project?) service, how would you go about this while maintaining clean domain model? Thanks, super useful and comprehensive video like the previous 2 from your ddd series.
Maybe I was not clear enough. You'll never inject a service in an aggregate!
If you're using a IDateTimeService then the Application layer would use that service to generate a datetime and it will pass it to the aggregate, either in the static factory method or in the constructor, depending on which way you choose to instantiate your aggregates.
Can you make a playlist for your ddd contents? i found alot of videos but i dont know where to start and thanks
All the DDD videos are already in a playlist: th-cam.com/video/kLLsVT_53bw/w-d-xo.html
Thanks for the good explanation but I am confused about ddd is it some approaches and patterns that I can implement some of it on need or it should be implemented all
DDD, as described initially by Eric Evans, comes with a lot of strategic and tactical design patterns. Some of them can be indeed adapted to non-DDD apps, but the more strategic ones that can't be adapted don't actually have to do only with code. It's also about team composition, ways of working and so on.
absolutely beautiful :). I have a question, if you need to take a large number of inputs when using a method of your aggregate, should you use a dto ?
Inputs is an application concept, usually involving a form. Therefore, you would use a DTO for that, not your domain model.
Keep going hope you do at the end a small project that uses DDD and EF and Clean Architecture
That's the plan!
Great video keep it up!. I have one question After the CompleteProject() called what if we want to maintain members for future reference how we gone handle such scenarios.
Well, you can simply not clear them as I did in the video.
Hello thanks for your efforts i have a little bit confused I will explain by an example if I have a room and this room has a Furnitures If I need to change the Furnitures of the room I should check some rules in the room. so, the room and Furnitures have a relationship so the room will be aggregate root and the Furnitures will be only entity but in the same time if I removed Furnitures that not mean that I need to remove the room so in this case there will be root aggregates so what is the correct
Great explanation! But i don't get how it will be work with DB? Could you explain this in future video?
Persistence is always tricky when it comes to DDD. also for value objects in general. I will create dedicated videos covering persistence strategies when using DDD.
Danke!
You're welcome. And thanks for the super!
I am beginning to wonder if it is even possible to implement Aggregates according to the stated rules. Perhaps Mauro Servienti was correct "All Our Aggregates Are Wrong". Please help me understand this.
Either Employee is an Aggregate or it is not.
If Employee is an Aggregate, then it should only be referenced by Id within the Project Aggregate. In this case, including Employee Entities in the Transactional Boundary of Project violates the most basic principles of Aggregate design. An Aggregate Root (Project) should be wholly responsible for managing the state of a contained entity. If Employee is its own Aggregate, then it can be modified outside the Transactional Boundary of its supposed Aggregate Root (ie Project).
If Employee is not an Aggregate, the situation here is perhaps worse. Project, the Aggregate Root, should completely manage the state of Employee objects. In fact, Project consumers shouldn't even know that Employee objects exist (just as Order consumers should not even know OrderLineItem exists). Currently, Employee objects are required to be instantiated outside of Project and passed in via a method. Calling this "full encapsulation" seems odd to me.
I really don't mean to be critical. I have yet to see an example, outside of the canonical Order/OrderLineItem, that actually adheres to the rules of Aggregate Design, as stated.
Please explain if I am incorrect as I really want to understand this.
Well, there's a reason why this video is part of a series.
The next video on the series answers your question. Please watch them all as a lot of things might get clearer: th-cam.com/video/E2ctgrKhqBw/w-d-xo.html
As a final word, DDD is complex and hard. That's why it only makes sense in very complex applications/domains where you'd probably have a microservices setup. For most other scenarios.
@@Codewrinkles Thanks. Will do.
Nice Bug picture.
Hopefully that picture kept you watching the video :)
FInally a DDD video that does not use same old bs example of Order and OrderItem xD
One of the reasons I did this video is because I was getting tired too of the exact same example anywhere. Thanks for watching and dropping a comment.
good try, But, you were not able to convince me why I should create aggregate rather than simple DM? I think you need to work harder on it
Well, the goal of the videos in this playlist is not to convince anybody about anything. It's just setting the DDD fundamentals. Some might find it useful.