I can´t thank you enough... I've learned a lot of concepts, but the most valuable lesson has been the fact that not every domain fit into this practisess; complexity is a choise, some times.
Had read the blue book till a point and the argument regarding the difference an organized namespace/folder structure makes stuck with me, but hadn't come across from anyone else such an example before. Kudos! Keep rocking!
We have been doing something similar. One difference is that we put all the aggregates in a folder called Aggregates. So the common folder doesn't get mixed up with the other aggregate folders. It works well, and have so not noticed any real downsides to this approach. One interesting idea is to use the new file nesting capabilities in visual studio. This could in theory do away with many folders. And you would be able to nest a value object for a specific entity.
Curious to hear what you thought about the implementation part of this video! Was it too fast? Too slow? Would you have preferred I hadn't skipped writing out the aggregate parts we already covered? Also, would you have preferred I actually wrote out the entire domain?
The implementation part as well as the entire tutorial was very explanatory, even if I used the pause function in few places :) Thanks again for your effort! Regarding the "functional" based folder structure; wouldn't the best location for the Error.User class be inside the "User" folder, or does Errors generally belong to the common folder?
Really enjoyed it. Speed was suitable, but i already was in touch with those concepts, so maybe for newbies could be a bit to fast (Since its a video, you can easily stop and manipulate speed ;) ). Implementing the whole domain is not needed, cause concept stays the same right. For me different approaches are more interesting. As example i would always go for the functional cohesion, instead of categorically. Just curious why you implemented additional value objects for the IDs, cause new creation of guid could be handled in base class. Also this post from Vaughn Vernon was very exciting, to decouple entities from the ORM with State-Objects. kalele.io/modeling-aggregates-with-ddd-and-entity-framework/ Best wishes, thanks :)
I have some question about your approach: - Why are you using value objects for ids? In most cases ids have little logic and it seems to be a redundant abstraction. We can use it wherever we have some logic more than simple comparison, and I don't get why you use it as a global pattern. - Why you use static factory method inside the class, instead of constructors? Constructors in this example are pretty simple, and we usually use factory methods when creating an object is complicated. Using factory method everywhere also seems redundant to me. Also I prefer factory classes rather than factory methods in such case, since this static methods nested inside the class will bloat the class the same as a big constructor will do (actually I don't see any differences between constructors and static factory methods at all). Factory methods in my opinion are suitable when used as a member method of a container class, a super class, etc. - Why all properties just have getters? How are you going to set them? What do you think about public setters on properties?
Ids should not have any logic at all. So having it as a value object is perfectly fine. As for the named constructor: Vo's are in general very small. So it does not bloat up the code too much. Named constructors are keeping your vo open for extension. Imagine having two of them. One is fromString and the other is fromInt or fromOtherVo. Also vos are responsible for them selves. So only they know how they are able to get instantiated. That's the reason for no external factory class
Always fun seeing how people organize this. Definitely agreed on colocation! Curious to see how the value objects will work for the foreign keys and what interactions with those and their entities will look like. Seems like you might need some interesting helpers on the value objects to facilitate interactions, but maybe there’s some other patterns to help here. Regardless, fun watch as always. Thanks for sharing 🍻
@@amantinband that’s any value object though. Dealing with the needs around a key are a separate issue I think with different needs. Doing things like an expanded GET list, managing child entities, etc would be interesting to see
Yeah, I wonder, why we create one more abstraction with ValueObject, if this suports "by default" on top of programming language itself. Ex: System.Guid (comparison, generating an so on)
What a nice series you're creating, Amichai! Congrats for the great work. One thing I was wondering is if u re gonna make something to not repeat the create/update props in each needed class.
Hi Amichai, Great Video really like the series, I think based on the gist in the description that maybe you should have an common entity with created/updated DateTime properties that inherit from the base entity class and then we can have less duplication of code to have it on each Entity we creating
Thanks שי. We'll have an IAuditableEntity interface that all the auditable entities will implement in the future. When we reach the persistence layer, we'll cover how to populate these properties.
I LOVE this series so far. Thanks for your effort in making it so smoothe and enjoable. Is there any chance that (in future) you could add some kind of keystrokes monitoring to your films and vs code shortcuts settings (your workflow is amazing)?
Don't you have multiple domains inside one project? Guests, menu, dinner etc? When you seperate each (sub) domain the initial structure isn't that bad?
Domain/Subdomain are logical boundaries. They do not necessarily have a 1:1 mapping to a project, system, or microservice. We would probably split this differently if we were designing a large system. But when starting out, it's definitely possible to start with a monolith and grow as needed. Does that make sense?
Directly instantiating a Guid inside the VO couples the Domain to the Infrastructure as it relies on the system's random device making it no longer "core" code. Do you have plans to move this to a Repository once they exist e.g. a NextIdentity method?
Yes, I had almost the same question about when it is the right time to generate an id for a entity/agragate root. And how the corresponding entity/agragate should live before this id will be generated? Suppose, it has to be a separate object. Thant YOU!
amazing series. One question, for the sake of garbage collector/memory allocation, shouldn't Ids be structures instead of classes? thank you for all this content
Thank you so much, Amichai, great work, keep it up. I personally enjoy you voice pitch and pace, make it much more enjoyable to listen complex explanitions. Hope this time I can FINALLY make it straight and logical in my head. P.S.: Can you say what's that suggetion tool at 8:30?
I'm not sure I understand how the AverageRating property on a Host and on a Dinner is kept up to date in this example. We said we want a change to an aggregate root not to affect other roots it is related to, but in this case the AverageRating depends on the content of the reviews. Would we need to subscribe to some MenuReviewCreated event to update the rating of the dinner and the host separately?Or is there another approach?
This video could not have been better timed, have been learning DDD for the past month or so for work and this cleared up a lot for me, Thank you! I have 1 question though, in your aggregates you define private read only list of value objects pointing to ids of other aggregates. How would you map this to a database? I'm using EF doing code first with FluentAPI and this is the only thing I'm struggling with
Amichai, thanks a lot for your videos We also need a tutorial how to connect all of these things to the database. What framework to use? Entity framework has a lot of constraints (on sealed classes, private members etc.) Thanks
Can you use Typescript for the implementation of the DDD for maybe just one video. I understand you don’t focus on It but will help folks like me anyways, I just watch the conceptual part of and then I have to skip the rest as I don’t code in that language. You explain the concept well so I appreciate your effort.
Great video Amichai... I have a question... Isnt it better to use records for implementing value objects ? I heard from Zoran Horvat that record types are mainly used for implementing value objects
The namespace and the class name (Menu.Menu) is really bothersome. May even cause issues when including the namespace somewhere else where, say, Menu would be used. Some experts out there use plural (Menus) or append Aggregate (MenuAggregate) to the folder/namespace. Hoping Amichai will explain how he tackles this issue. Great video as always.
Thanks for bringing this up. I found the folder names/namespaces to be a bit bothersome as well. Thanks for the recommendation and for future readers, this is addressed in this video: ua-cam.com/video/jm0CWlb5vvQ/v-deo.html
First things first: I really like this structure. I am new to Clean Architecture and just recently heard about vertical (or feature) slicing. One thing this structure does, however, is require a qualification when referencing the aggregate root. For example: public void AddDinner(Dinner.Dinner dinner) . Does this bother anyone else or is this a standard practice and I just need to get over the redundancy? I know this is probably just my weirdness, but thought I'd ask.
I'm surprised no one has commented on this but you! This is definitely an issue when the namespace and the class name are the same. We'll cover it in a future video 🙂
I asked myself the same question. I'm really curious how you're going to solve this. Could it be that the solution is for the aggregate folder to be plural??
Hi Amichai! Awesome videos. They have really been missing everywhere on the internet. Definitely the best ones on the subject. One question: Is it really good to force passing an Id in the constructor? Normally the database would decide the Id and set it. Can you tell me why this is a good approach? Or are you planning on rewriting it later when you add the persistence layer and EF?
Hey Matthias! Great question. Depends on your approach. Some prefer having the repository/persistence generate the id, some prefer the something similar to what I presented. We’ll cover both approaches in the series 🤙🏼
What an effort made keep it up (Y) Quick Notes though : 1. regarding the readonly issue modify the public Ireadonlylist Items to be public ReadOnlyCollection this is not castable to List 2. please Could you order the videos in the Domain-Driven Design PlayList in a chronological order Thanks a lot
@Amichai Thank you again for all your effort, every lesson is greater. I would like to ask you something that is really urgent to me: How can I dockerize a project like this we are studying with you for deploying as a container on a cloud? Please, Can you or another people here, share the way or an example to achieve it? Thanks a lot, you’re amazing!
Super cool series, I have watched all 13 videos now, and i learned a lot from these. I am curious about the plan of upcoming videos ? Do you have a plan ? Fx Logging, Persistence, Events, Versioning ?
Clear as always, looking at the "homework" and specially at Dinner.Status and DinnerReservation.ReservationStatus, I guess one of the next videos will also cover enums?
Yeah, perhaps I should have put an example of an Enum in today's video, didn't think about it 🤦♂️ For now, you can either use native Enums or Ardalis's SmartEnums. I'll make sure to cover it in one of the upcoming videos. Thanks for commenting!
Hello Amichai, I had a bread from your course because lack of time.. I see that you mafe your repository with buber dinner private. I was following your videos from the beginning and I have a public repo with my code. Can I leave it as public? Your new videos are full of knowledge that I was looking for 😀 Great work
There is a lot of knowledge missing regarding this topic. My last company started adapting this style 6 months ago in new projects and I felt they were early adapters. Are there other sources besides you or working with Microsoft to obtain this information?
I really like this video, this removes a lots of confusions in my mind, just curious about where should I put domain services? also under those folders for each aggregate? will that part be covered in upcoming episodes? Really appreciate it 😀
Good way to explain :) I can only suggest to speak less fast :) Maybe 70% of the current speed as it causes some kind of pressure :) on an average mind processing the new knowledge/howtos etc... But, general layout and approach to explain DDD with code practice is quite good. Thanks!
Hi, its an amazing video tutorial - I've watched it in one week :-). But I am missing a nother big topic in your videos - what about logging? How do you log Errors, debugging Informations and so on? Thanks a lot for your tutorials.
Fantastic explanation and implementation😍 ... I wish I could be one of your patreon but online payment is not applicable in our country. Is there an option to become your patreon to access the source code?
Hi Amichai, im trying to configure the Id's and relations id's between aggregates with entity framework and i dont find a solution how to do it. I think that its simplier putting the type Guid instead of the value object in this case
Hi Nicolas. We’ll cover this in depth in the upcoming videos. Generally, I like to design the domain as if the objects are stored in memory and then bend the persistence layer to support this idea. Changing the domain to support persistence is the last resort in my book
hey, thanks for the video although I have a different view angle here you totally ignored the bounded context here. and most of the time each bounded context gonna have only one aggregate. so if you considered the bounded contexts each context would be independent and there would be no common directory between them
@@mabdullahsari intresting! I wonder why a bounded context has multiple aggregations !! also, he divided the project directory into different related functionalities (Dinner, Bill, Guest...) for a simple domain, most of the time a bounded context is the subdomain but if the sub-domain serves different functionalities then we have to divide it into multiple bounded contexts
You can define multiple constructors for different purposes while keeping the state consistent. The internal workings of the object can be changed without worrying about breaking the clients that consume the said object. It also adds *meaning* when used correctly, I wouldn't agree with Create here necessarily though as it's very CRUD-dy. Member.Invite(...) Session.Plan(...) Permission.Assign(...) etc. these make use of the Ubiquitous Language.
Thanks again for the great videos! MenuSections and MenuSectionsItems are entities within the Menu Aggregate Root. This makes sense, especially by the Cascading Delete Rule. However, I can't see the difference between those and MenuReview. Shouldn't MenuReview be a collection of entities just as MenuSections? You are treating MenuReviews the same as Dinners. However, if you delete a Menu, then there would be no MenuReviews, but the Dinner would not be deleted.
Hey Vincent! I cover this in previous videos - generally, we prefer having more aggregates if possible. This is for concurrency, memory and latency reasons. We will merge two aggregates to one when there are some constraints. These constraints can be forcing invariants or perhaps eventual consistency cannot be tolerated. Does that make sense?
The problem with DDD aproach is: There is no formalized approach how to do this. Its some kind philosophy tailored per team/teams/whatever structure it is. Now you can say we do the same way as this guy on youtube. Some folks do different way, some others do another way. As long its have DDD "principles" described in Evans book and extended by Vernon, everything else is just architecture software approach for particular application.
Select the range and the press CTRL+SHIFT+L to "Selection => Select All Occurrences", personally I always use just hold down CTRL+D which results in "Selection => Select Next Occurrence"
I like a lot your material, there are a lot of great stuff presented and a lot to learn, but I personally I hate DDD for the fact that classes (object oriented) define the domain, I prefer to have "services" interfaces as fist class citizens, therefore writing any line of implementation is after I have the pipelines "contracts" get defined. And what I hate the most on DDD, unit test does find the problem in the domain quickly, but apart from domain validity does absolutely nothing in a SOA architecture, and no, I don't have a problem with unit test, i have a problem with code coverage of 100% won't find any of the integration issues.
until the end of the Part13 , i was happy. because , i could see all source code on UA-cam , but , i can not see all domainmodels source code now. and i have to pay money?? i im very disppointed. my long time watstes
I can't even imagine how much effort it takes to prepare a series of tutorials on this topic. Thank you so much! looking forward for the next one!
Thanks, Turgay. My wife would agree it's way too much effort 😅
I cannot explain how much I appreciate your work. This is such an incredibly useful and decent series.
Thanks, Ibrahim 🙏🏼
I can´t thank you enough... I've learned a lot of concepts, but the most valuable lesson has been the fact that not every domain fit into this practisess; complexity is a choise, some times.
Had read the blue book till a point and the argument regarding the difference an organized namespace/folder structure makes stuck with me, but hadn't come across from anyone else such an example before. Kudos! Keep rocking!
Your tutorials are so great but I'm watching them at 0.75 speed. ;-). Much better.
We have been doing something similar. One difference is that we put all the aggregates in a folder called Aggregates. So the common folder doesn't get mixed up with the other aggregate folders.
It works well, and have so not noticed any real downsides to this approach. One interesting idea is to use the new file nesting capabilities in visual studio. This could in theory do away with many folders. And you would be able to nest a value object for a specific entity.
I have been following this series from day 1. Its very informative. I really appreciate your work. Thanks for sharing your knowledge.
It's amazing how the folder structure can change the way how you approach all other decisions. 👏👏👏
💯
I've never seen these approaches before, it's super clean, thanks for sharing with us!
Curious to hear what you thought about the implementation part of this video! Was it too fast? Too slow? Would you have preferred I hadn't skipped writing out the aggregate parts we already covered? Also, would you have preferred I actually wrote out the entire domain?
The implementation part as well as the entire tutorial was very explanatory, even if I used the pause function in few places :) Thanks again for your effort! Regarding the "functional" based folder structure; wouldn't the best location for the Error.User class be inside the "User" folder, or does Errors generally belong to the common folder?
Really enjoyed it. Speed was suitable, but i already was in touch with those concepts, so maybe for newbies could be a bit to fast (Since its a video, you can easily stop and manipulate speed ;) ).
Implementing the whole domain is not needed, cause concept stays the same right. For me different approaches are more interesting. As example i would always go for the functional cohesion, instead of categorically. Just curious why you implemented additional value objects for the IDs, cause new creation of guid could be handled in base class.
Also this post from Vaughn Vernon was very exciting, to decouple entities from the ORM with State-Objects. kalele.io/modeling-aggregates-with-ddd-and-entity-framework/
Best wishes, thanks :)
It seems a little fast, but skipping the writing of similar aggregate parts makes sense.
I have some question about your approach:
- Why are you using value objects for ids? In most cases ids have little logic and it seems to be a redundant abstraction. We can use it wherever we have some logic more than simple comparison, and I don't get why you use it as a global pattern.
- Why you use static factory method inside the class, instead of constructors? Constructors in this example are pretty simple, and we usually use factory methods when creating an object is complicated. Using factory method everywhere also seems redundant to me. Also I prefer factory classes rather than factory methods in such case, since this static methods nested inside the class will bloat the class the same as a big constructor will do (actually I don't see any differences between constructors and static factory methods at all). Factory methods in my opinion are suitable when used as a member method of a container class, a super class, etc.
- Why all properties just have getters? How are you going to set them? What do you think about public setters on properties?
Ids should not have any logic at all. So having it as a value object is perfectly fine. As for the named constructor: Vo's are in general very small. So it does not bloat up the code too much. Named constructors are keeping your vo open for extension. Imagine having two of them. One is fromString and the other is fromInt or fromOtherVo. Also vos are responsible for them selves. So only they know how they are able to get instantiated. That's the reason for no external factory class
Setters: Vo's are immutable and this is their main job
Always fun seeing how people organize this. Definitely agreed on colocation!
Curious to see how the value objects will work for the foreign keys and what interactions with those and their entities will look like. Seems like you might need some interesting helpers on the value objects to facilitate interactions, but maybe there’s some other patterns to help here.
Regardless, fun watch as always. Thanks for sharing 🍻
I've been wondering this myself, and in case Amichai uses EF Core if everything he's done so far will play nice. Looking forward to this.
Yup, we'll deal with this when we cover entity type configurations. Basically, we'll use the HasConversion method for this.
@@amantinband that’s any value object though. Dealing with the needs around a key are a separate issue I think with different needs. Doing things like an expanded GET list, managing child entities, etc would be interesting to see
Yeah, I wonder, why we create one more abstraction with ValueObject, if this suports "by default" on top of programming language itself. Ex: System.Guid (comparison, generating an so on)
What a nice series you're creating, Amichai! Congrats for the great work. One thing I was wondering is if u re gonna make something to not repeat the create/update props in each needed class.
Thanks, Hugo. No, I don't have a technique for that. Do you have something in mind?
Great video, Amichai! Looking forward to the persistence implementation. Thank you very much.
Thanks, Roberto! Me too 🤙🏼
Hi Amichai, Great Video really like the series, I think based on the gist in the description that maybe you should have an common entity with created/updated DateTime properties that inherit from the base entity class and then we can have less duplication of code to have it on each Entity we creating
Thanks שי. We'll have an IAuditableEntity interface that all the auditable entities will implement in the future. When we reach the persistence layer, we'll cover how to populate these properties.
I LOVE this series so far. Thanks for your effort in making it so smoothe and enjoable.
Is there any chance that (in future) you could add some kind of keystrokes monitoring to your films and vs code shortcuts settings (your workflow is amazing)?
Thanks! I tried in a draft video. I felt it added too much noise to the screen 🤷🏼♂️
Don't you have multiple domains inside one project? Guests, menu, dinner etc? When you seperate each (sub) domain the initial structure isn't that bad?
Domain/Subdomain are logical boundaries. They do not necessarily have a 1:1 mapping to a project, system, or microservice.
We would probably split this differently if we were designing a large system. But when starting out, it's definitely possible to start with a monolith and grow as needed. Does that make sense?
Great coding without a single look on a keyboard!)
Directly instantiating a Guid inside the VO couples the Domain to the Infrastructure as it relies on the system's random device making it no longer "core" code. Do you have plans to move this to a Repository once they exist e.g. a NextIdentity method?
Yes, I had almost the same question about when it is the right time to generate an id for a entity/agragate root. And how the corresponding entity/agragate should live before this id will be generated? Suppose, it has to be a separate object. Thant YOU!
Great comment. It's the topic of a future video 🫣
amazing series. One question, for the sake of garbage collector/memory allocation, shouldn't Ids be structures instead of classes? thank you for all this content
great video on a complex subject - thanks!
Thank you so much, Amichai, great work, keep it up. I personally enjoy you voice pitch and pace, make it much more enjoyable to listen complex explanitions.
Hope this time I can FINALLY make it straight and logical in my head.
P.S.: Can you say what's that suggetion tool at 8:30?
Thanks! It’s GitHub Co-Pilot
I'm not sure I understand how the AverageRating property on a Host and on a Dinner is kept up to date in this example.
We said we want a change to an aggregate root not to affect other roots it is related to, but in this case the AverageRating depends on the content of the reviews.
Would we need to subscribe to some MenuReviewCreated event to update the rating of the dinner and the host separately?Or is there another approach?
This video could not have been better timed, have been learning DDD for the past month or so for work and this cleared up a lot for me, Thank you!
I have 1 question though, in your aggregates you define private read only list of value objects pointing to ids of other aggregates. How would you map this to a database? I'm using EF doing code first with FluentAPI and this is the only thing I'm struggling with
Awesomely great video, well structed and presented. Thanks a lot!
This is a GREAT JOB!!! I love this series, was fantastic thank you!
Who takes care of populating fields in an aggregate?
Does the query take care of calling each repository and put set them as an aggregate entities?
Great stuff👍
I'm wondering where the other parts are. This is part 13 but the playlist only contains 7 videos 🤔
Best guides about DDD! Thanks, man
Great video thank you❤. What about structuring DDD with N-Tier architecture?
Excellent explanation and series so far, good job!
how many episodes are planned, very interesting
Thanks, Belka. We haven't touched persistence using EF Core & Testing yet, which are rich topics, so I'd say there are at least 8 videos left.
Can't wait for the next one!
Hello, can you please tell how numeric value can be used as Value Object and create it uniquely instead of GUID?
Can someone explain, what is the idea behind those "EntityId" objects and inheriting from them? What is the benefit?
I loved it. Thank you!
🫶🏼
Amichai, thanks a lot for your videos
We also need a tutorial how to connect all of these things to the database. What framework to use? Entity framework has a lot of constraints (on sealed classes, private members etc.)
Thanks
Can you use Typescript for the implementation of the DDD for maybe just one video. I understand you don’t focus on It but will help folks like me anyways, I just watch the conceptual part of and then I have to skip the rest as I don’t code in that language. You explain the concept well so I appreciate your effort.
Awesome playlist! are you planning on making any more videos for this series?
Great video Amichai... I have a question... Isnt it better to use records for implementing value objects ? I heard from Zoran Horvat that record types are mainly used for implementing value objects
Great Series! Thank you!
Supercool series. Is there gonna be more chapters? Also, are plans to show database integration (I suppose it goes to the infrastructure project)?
Thanks! Yes and yes. Persistence via EF Core is the upcoming section in the series 🤙🏼
Awesome! Thank you
1:37 What is the difference between Aggregate vs entity, Could i persist aggregate or Only the entity can be persisted
You're doing great, keep it up.
The namespace and the class name (Menu.Menu) is really bothersome. May even cause issues when including the namespace somewhere else where, say, Menu would be used. Some experts out there use plural (Menus) or append Aggregate (MenuAggregate) to the folder/namespace. Hoping Amichai will explain how he tackles this issue. Great video as always.
Thanks for bringing this up. I found the folder names/namespaces to be a bit bothersome as well. Thanks for the recommendation and for future readers, this is addressed in this video: ua-cam.com/video/jm0CWlb5vvQ/v-deo.html
Great videos, thank you!
Great explanation
First things first: I really like this structure. I am new to Clean Architecture and just recently heard about vertical (or feature) slicing. One thing this structure does, however, is require a qualification when referencing the aggregate root. For example: public void AddDinner(Dinner.Dinner dinner) . Does this bother anyone else or is this a standard practice and I just need to get over the redundancy? I know this is probably just my weirdness, but thought I'd ask.
I'm surprised no one has commented on this but you! This is definitely an issue when the namespace and the class name are the same. We'll cover it in a future video 🙂
I asked myself the same question. I'm really curious how you're going to solve this. Could it be that the solution is for the aggregate folder to be plural??
Hi Amichai! Awesome videos. They have really been missing everywhere on the internet. Definitely the best ones on the subject.
One question: Is it really good to force passing an Id in the constructor? Normally the database would decide the Id and set it. Can you tell me why this is a good approach? Or are you planning on rewriting it later when you add the persistence layer and EF?
Hey Matthias! Great question. Depends on your approach. Some prefer having the repository/persistence generate the id, some prefer the something similar to what I presented. We’ll cover both approaches in the series 🤙🏼
What an effort made keep it up (Y)
Quick Notes though :
1. regarding the readonly issue modify the public Ireadonlylist Items to be public ReadOnlyCollection this is not castable to List
2. please Could you order the videos in the Domain-Driven Design PlayList in a chronological order
Thanks a lot
Why is MenuSection a Entity here and not a ValueObject? Like why are only Ids ValueObjects?
i'm light years behind this
Hi, can you help.... why menuesection or menueitem are entities and not valueobjects? Do they have a life ?
@Amichai Thank you again for all your effort, every lesson is greater. I would like to ask you something that is really urgent to me: How can I dockerize a project like this we are studying with you for deploying as a container on a cloud? Please, Can you or another people here, share the way or an example to achieve it? Thanks a lot, you’re amazing!
very goooood!!!!❤ ty for the content
Why did you use class instead of record when declaring the entities? World think that record would be better in this scenario
Uh-oh, I smell domain model anemia.
Super cool series, I have watched all 13 videos now, and i learned a lot from these. I am curious about the plan of upcoming videos ? Do you have a plan ? Fx Logging, Persistence, Events, Versioning ?
Thanks Michael! Yes, I’m planning to cover all these topics in the future 🤙🏼
Clear as always, looking at the "homework" and specially at Dinner.Status and DinnerReservation.ReservationStatus, I guess one of the next videos will also cover enums?
Yeah, perhaps I should have put an example of an Enum in today's video, didn't think about it 🤦♂️
For now, you can either use native Enums or Ardalis's SmartEnums. I'll make sure to cover it in one of the upcoming videos. Thanks for commenting!
Great work amichai although do you mind teaching us the magic spell used at 13:23 ??
Thank you for the video! One question: what about integers? I mean if I want to use int as ID, how I should generate it in “CreateUniq”?
@Amichai Mantinband so designing aggregates like this - Can we safely say that it is following feature slicing approach?
I noticed for domains you took a vertical slice approach why not continue to the architecture/ structure of the project also?
I like maintaining the cohesion when possible. The projects are separated following CA, the internal separation however, as you said is by feature
@@amantinband are you using CA for projects for the tutorial series to demonstrate CA? If so, do you use or would you consider using VSA?
Hey man, great video.
Is immutable list better choice in this case then read only list (12:15)?
It's little bit not about domains when you splitting classes by folders of class-types. Folder name should represent - domain.
Hello Amichai,
I had a bread from your course because lack of time.. I see that you mafe your repository with buber dinner private. I was following your videos from the beginning and I have a public repo with my code.
Can I leave it as public?
Your new videos are full of knowledge that I was looking for 😀 Great work
Of course! 🫶🏼
There is a lot of knowledge missing regarding this topic. My last company started adapting this style 6 months ago in new projects and I felt they were early adapters. Are there other sources besides you or working with Microsoft to obtain this information?
Will it be working with EF, Dapper ? Yours constructors always make new ID (primary key ?) , what's is incompliance with Database schema, is it ?
I really like this video, this removes a lots of confusions in my mind, just curious about where should I put domain services? also under those folders for each aggregate? will that part be covered in upcoming episodes? Really appreciate it 😀
The Red DDD book by VV covers this.
You need to introduce an additional level:
Domain.Model
Domain.Service
Amichai's classes fall under Domain/Model.
@@mabdullahsari much appreciate it mate 🙏
Hello csharper, .md is for mark down! Change that to .dm for domain.
Amazing 👍
What is an application used to describe in 40s of the video
Why you do not use int as type ids in your models? you use only string and Guid
Good way to explain :) I can only suggest to speak less fast :) Maybe 70% of the current speed as it causes some kind of pressure :) on an average mind processing the new knowledge/howtos etc... But, general layout and approach to explain DDD with code practice is quite good. Thanks!
5:00 - Feature Slicing
Are you going to use Entity Framework in this course?
Hi, its an amazing video tutorial - I've watched it in one week :-). But I am missing a nother big topic in your videos - what about logging? How do you log Errors, debugging Informations and so on? Thanks a lot for your tutorials.
Thanks! We’ll cover logging in a future video 🤙🏼
Fantastic explanation and implementation😍 ... I wish I could be one of your patreon but online payment is not applicable in our country. Is there an option to become your patreon to access the source code?
@@amantinband i really thank you
what's the estimated date of finishing this series?
Hi Amichai, im trying to configure the Id's and relations id's between aggregates with entity framework and i dont find a solution how to do it. I think that its simplier putting the type Guid instead of the value object in this case
Hi Nicolas. We’ll cover this in depth in the upcoming videos. Generally, I like to design the domain as if the objects are stored in memory and then bend the persistence layer to support this idea. Changing the domain to support persistence is the last resort in my book
hey, thanks for the video
although I have a different view angle here
you totally ignored the bounded context here. and most of the time each bounded context gonna have only one aggregate.
so if you considered the bounded contexts each context would be independent and there would be no common directory between them
I think your understanding of Bounded Context is lacking here.
BuberDinner **is** the Bounded Context.
@@mabdullahsari intresting!
I wonder why a bounded context has multiple aggregations !!
also, he divided the project directory into different related functionalities (Dinner, Bill, Guest...)
for a simple domain, most of the time a bounded context is the subdomain but if the sub-domain serves different functionalities then we have to divide it into multiple bounded contexts
Hi, thanks a lot for your videos! What is the purpose of making the ctor private and using a static factory instead?
You can define multiple constructors for different purposes while keeping the state consistent.
The internal workings of the object can be changed without worrying about breaking the clients that consume the said object.
It also adds *meaning* when used correctly, I wouldn't agree with Create here necessarily though as it's very CRUD-dy.
Member.Invite(...)
Session.Plan(...)
Permission.Assign(...)
etc. these make use of the Ubiquitous Language.
@@mabdullahsari thank you!
Thanks again for the great videos! MenuSections and MenuSectionsItems are entities within the Menu Aggregate Root. This makes sense, especially by the Cascading Delete Rule. However, I can't see the difference between those and MenuReview. Shouldn't MenuReview be a collection of entities just as MenuSections? You are treating MenuReviews the same as Dinners. However, if you delete a Menu, then there would be no MenuReviews, but the Dinner would not be deleted.
Also, GuestRating is a collection of entities within Guest. Shouldn't the same be true for MenuReview within Menu? Really trying to understand.
Hey Vincent! I cover this in previous videos - generally, we prefer having more aggregates if possible. This is for concurrency, memory and latency reasons. We will merge two aggregates to one when there are some constraints. These constraints can be forcing invariants or perhaps eventual consistency cannot be tolerated. Does that make sense?
what is the shortcut for creating folders and files like you?
I think I configured them both manually. I use ctrl-shift-n for folder and ctrl-n for file
The problem with DDD aproach is: There is no formalized approach how to do this. Its some kind philosophy tailored per team/teams/whatever structure it is. Now you can say we do the same way as this guy on youtube. Some folks do different way, some others do another way. As long its have DDD "principles" described in Evans book and extended by Vernon, everything else is just architecture software approach for particular application.
At the 8:55 mark you replace every occurrence of "MenuId" with "MenuSectionId" - how did you select all instances of MenuId? That was no Ctrl+H !!
Select the range and the press CTRL+SHIFT+L to "Selection => Select All Occurrences", personally I always use just hold down CTRL+D which results in "Selection => Select Next Occurrence"
Vim -> :%s/MenuId/MenuSectionId/g 😁
I kinda don't get why you're creating an entire class around an Id.
Can you explain or link a resource?
Check out my video on the Identity paradox
@@amantinband Just watched it. Perfect! Thanks!
I like a lot your material, there are a lot of great stuff presented and a lot to learn, but I personally I hate DDD for the fact that classes (object oriented) define the domain, I prefer to have "services" interfaces as fist class citizens, therefore writing any line of implementation is after I have the pipelines "contracts" get defined. And what I hate the most on DDD, unit test does find the problem in the domain quickly, but apart from domain validity does absolutely nothing in a SOA architecture, and no, I don't have a problem with unit test, i have a problem with code coverage of 100% won't find any of the integration issues.
why am I, a JavaScript developer, watching C syntax here only to learn DDD T_T
until the end of the Part13 , i was happy. because , i could see all source code on UA-cam , but , i can not see all domainmodels source code now. and i have to pay money?? i im very disppointed. my long time watstes
Only I hate 'common' naming?
Vaughn Vernon prefers Common.
He's the 2nd most credible person right after Eric Evans.
Too much typing. Different classes for IDs??!