+1 for explanation from scratch. +1 for explaining a common case where a domain does not really need to be rich for productivity. +1 for detailed examples. Great video, looking out for more content as usual!
Good explanation! One Point to mention is that you dont need all those factory methods. Just use standard public ctor! This makes It more clear what a new instance requires to be created when using new keyword.
One reason I prefer factory methods is ORMs - they'll call the ctor when materializing objects from the database. And I can add side-effects with factory methods which don't really fit inside a ctor.
@@MilanJovanovicTech this is right! But then you have kind of a persistence aware domain, so its a design decision. Another solution is to add a private ctor when orm needs to intantiate an object, which is also persistence aware (but this time with 'new-keyword flavor'). What do you mean with side-effects? If you want to have different creation behaviours? Also fit into ctor
I have a good base with this video which allows me to follow other of your videos or see again those already seen. I learn new good things from you every time. Thank you so much!
Great post. One additional thing to consider is that data validator functions often live "somewhere else" than the data, especially in cloud scenarios. A functional approach to this problem might be to have a domain model that imagines both an Order entity, and a ValidatedOrder entity. And then, any functionality that relies on an order being validated can take an explicit dependency on ValidatedOrder (produced by an OrderValidator, of course!). "init" and "required" properties can help with baseline completeness, in the meantime. I'd still consider this a rich domain model, but the richness is pushed to the functions/actions, not the data.
I'm glad you think so, because I spent countless hours studying DDD 😅 I'll be releasing an in-depth course next month about Clean Architecture and DDD, where I'll do a much better job of explaining everything.
@@MilanJovanovicTech Thank you, good to know that. Indeed DDD is a very debatable topic. I see more and more developers not favouring it, but I also see very bad implementations of it which I think leads to the first one.
Thanks for the video. It looks very nice at first sight. However, it gets complicated when you look at a real application. For a line item you might need 12 parameters or more. You don't want to pass those as parameters, so you need another DTO class, which of course again contains public set or init. You also need to be able to change the line items afterwards. So for every little thing a separate function - SetQuantity(), AddDiscount() etc. . This turns a "rich domain model" quickly into a "fat domain model".
Very good examples, about antipattern or patterns , we have a lot and allways depends of the context I prefer to consider as a different way and not as an anti pattern. Also remember that for few ORMs you need to do some configurations to save private properties in the db. For example if you want to save a complex object with private properties in cosmos db.
Great concise explanation of what the Anemic Domain Model is, but the video didn't really discuss the question posed in the title "Is an Anemic Domain Model an Anti-Pattern?" I get what the disadvantages of the ADM is and how the RDM addresses those. And I think we all know that the ADM is commonly considered an anti-pattern. Or at least, that's how Martin Fowler described it when he coined the term. But I was hoping this video would delve into that discussion a bit more and maybe suggest why it might not be considered an anti-pattern. Otherwise a title of "What is the Anemic Domain Model" would perhaps have been more accurate. Great content nevertheless. Milan is my goto channel for .NET related topics, hands down.
You can extract the business logic of order creation into it's own component that doesn't have state. You can do the same without mixing state and logic. Basically like in a functional programming languages. In realistic scenarios your domain model code will have external dependencies like EF or some external services. It could get ugly when you have to supply those dependencies to your domain model. Well I guess thats DDD.
I appreciate your efforts to make DDD approachable, most books do more talking than showing code. I have some questions though. Is it really good to use record types for value objects? I have found them so lacking. 1. We simply can’t use their awesome primary constructor. Why? It breaks domain invariants. There is validation. In most cases we prefer the smart constructor pattern. 2. They don’t implement IComparable out of the box. Say I want to return products that code less than a given price? Money has to implement IComparable for that to work. 3. Their comparison semantics are lacking especially when the value object contains some sort of collection. Some times we don’t want to use all the values for comparison. I came across a lib that provides a full fledged ValueObject class that provides all this plumberinf for free. What are your thoughts on this?
I've switched to using records and I'm not looking back. The drawbacks are negligible most of the time. The problem with collection is they are reference types, not in the record itself.
@@MilanJovanovicTech Yeah I agree with you on this. Most code bases can live happily with value objects as records. I didn’t say that the problem is with the record, I said if it contains a reference type (collection) then we need something else. Thanks
Good video, just one comment- Properties/Collections being accessed directly is indeed an anti-pattern to the point where it has a name- Law of Demeter.
Hi, Milan. Thanks for your great work. It would be nice if you make videos about ef core. Targeting more deep view on how it works. Like when it creates database connection etc.
Thx for great explanation. However maybe unpopular opinion over here from practices you can achieve great things even with ’anemic models’ even in pretty big systems if your resource accessor layer has the well defined operations around atomic business verbs.
@@MilanJovanovicTech That would be great. I'm always working with ADM and this approach would really improve my codebase. Would love to see full example with EF!
How to you instantiate this model when you load the data from the database if the constructor is private? You cannot really call "create()" as that's not a new entity
@@MilanJovanovicTech by manually, you mean that the constructor should be public or that we should create another static method to instantiate a domain entity from a dataset?
How to work with EF in this case? Are you going to have another entity class for the database? It would be nice to see the full workflow where you still have OrderService and you need to have a mapping between your Order class which encapsulates logic and your Order entity class. How would repository implementation look like?
The best is to make the code pass all of them. In my team we have configured our projects to treat these warnings as errors, so Visual Studio won't build if those are not resolved.
Hi Milan! Greetings from Brazil! Could you make a video about the best way to use DDD (rich domain) with EF CORE? I have two screens that use different attributes but have one constructor. How can I implement the best select function? For example, for one screen, I need to select only the product ID: context.Product.select(product => product.Id). For another screen, I need to select only the product name: Context.product.select(product => product.Name). Do you recommend using two constructors in the same class? I apologize for my poor English. Your videos are great!
At 4:18 you mentioned that there could be more than one places to create order. Why would one implement it that way isn't that what the OrderService is for? If you need to create an order you inject the order service and call the create method no? Where else or why would you implement the order create somewhere else? Maybe I'm too inexperienced to wrap my head around this. Please can you explain?
if we make the setters and constructors private, will we be able to use Entity framework? doesn't entity framework be able to create the domain instances when we are querying data from database?
I strongly desagree with your view. A POCO class like your orde class, should never contain logic, Single responsability Principle, leave the logic to a service. Make testing and abstraction so much easier and organized. Animic classes is somehting that i always enforce in my teams
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Are there Authentication and Authorization in your lessons using Clean Architecture, Milan?
@@datka89 You mean course? 🤔
+1 for explanation from scratch. +1 for explaining a common case where a domain does not really need to be rich for productivity. +1 for detailed examples. Great video, looking out for more content as usual!
I'll try to keep it like this in the future videos, but for some topics I really can't start from scratch 😁
@@MilanJovanovicTech totally understand, appreciate it
I like that you make example from scratch, you show the problem and then the solution
The correct way to learn, IMO
Good explanation! One Point to mention is that you dont need all those factory methods. Just use standard public ctor! This makes It more clear what a new instance requires to be created when using new keyword.
One reason I prefer factory methods is ORMs - they'll call the ctor when materializing objects from the database.
And I can add side-effects with factory methods which don't really fit inside a ctor.
@@MilanJovanovicTech this is right! But then you have kind of a persistence aware domain, so its a design decision. Another solution is to add a private ctor when orm needs to intantiate an object, which is also persistence aware (but this time with 'new-keyword flavor'). What do you mean with side-effects? If you want to have different creation behaviours? Also fit into ctor
I have a good base with this video which allows me to follow other of your videos or see again those already seen. I learn new good things from you every time. Thank you so much!
Awesome, glad it's helpful :)
I just noticed you're almost at 50k subscribers. Well done man, keep it up :)
Getting there! A few more days and we should get 50k. Gotta start planning some surprise 😁
Thank you for the video. Waiting for the video where you will explain how to work with rich model Order and database.
That'll be coming out next week 😁
Nice and structured explanation! Big applause for mentioning pros of having anemic domain model and cases. Well done!
Much appreciated!
I love your videos so much! You go from zero to hero in every one of your videos.
Wow, thank you!
Watching you from Cameroon. Great content. I learn a lot from your videos.
Much love for Africa. I'm happy you're finding the videos insightful. 😁
Great post. One additional thing to consider is that data validator functions often live "somewhere else" than the data, especially in cloud scenarios. A functional approach to this problem might be to have a domain model that imagines both an Order entity, and a ValidatedOrder entity. And then, any functionality that relies on an order being validated can take an explicit dependency on ValidatedOrder (produced by an OrderValidator, of course!). "init" and "required" properties can help with baseline completeness, in the meantime. I'd still consider this a rich domain model, but the richness is pushed to the functions/actions, not the data.
That's quite a peculiar approach. Do you have any resources about that?
@@MilanJovanovicTech Scott Wlaschin's "Domain Modeling Made Functional" book and lectures would be a start.
See, e.g. EmailValidationService discussion in his 2019 KanDDDinsky talk on YT.
This DDD series is the best explanation for DDD I've ever seen online.
I'm glad you think so, because I spent countless hours studying DDD 😅
I'll be releasing an in-depth course next month about Clean Architecture and DDD, where I'll do a much better job of explaining everything.
@@MilanJovanovicTech Thank you, good to know that. Indeed DDD is a very debatable topic. I see more and more developers not favouring it, but I also see very bad implementations of it which I think leads to the first one.
Thanks for the video. It looks very nice at first sight.
However, it gets complicated when you look at a real application. For a line item you might need 12 parameters or more. You don't want to pass those as parameters, so you need another DTO class, which of course again contains public set or init. You also need to be able to change the line items afterwards. So for every little thing a separate function - SetQuantity(), AddDiscount() etc. . This turns a "rich domain model" quickly into a "fat domain model".
If you focus on "behavior" it starts making sense - regardless of the number of properties. You don't need a SetX method for each property
Very good examples, about antipattern or patterns , we have a lot and allways depends of the context I prefer to consider as a different way and not as an anti pattern. Also remember that for few ORMs you need to do some configurations to save private properties in the db. For example if you want to save a complex object with private properties in cosmos db.
With EF Core that's relatively easy to do
Great one as usual milan 🔥
Thank you!
your videos are awesome, i am learning very much with each video, each pattern wath you teach and show is very usefull
Happy to hear that!
Great concise explanation of what the Anemic Domain Model is, but the video didn't really discuss the question posed in the title "Is an Anemic Domain Model an Anti-Pattern?" I get what the disadvantages of the ADM is and how the RDM addresses those. And I think we all know that the ADM is commonly considered an anti-pattern. Or at least, that's how Martin Fowler described it when he coined the term. But I was hoping this video would delve into that discussion a bit more and maybe suggest why it might not be considered an anti-pattern. Otherwise a title of "What is the Anemic Domain Model" would perhaps have been more accurate.
Great content nevertheless. Milan is my goto channel for .NET related topics, hands down.
I appreciate the feedback very much!
You can extract the business logic of order creation into it's own component that doesn't have state. You can do the same without mixing state and logic. Basically like in a functional programming languages. In realistic scenarios your domain model code will have external dependencies like EF or some external services. It could get ugly when you have to supply those dependencies to your domain model. Well I guess thats DDD.
Of course, it's possible to use a domain service to extract that logic. There's no need to introduce external dependencies to domain models though.
I appreciate your efforts to make DDD approachable, most books do more talking than showing code.
I have some questions though. Is it really good to use record types for value objects? I have found them so lacking.
1. We simply can’t use their awesome primary constructor. Why? It breaks domain invariants. There is validation. In most cases we prefer the smart constructor pattern.
2. They don’t implement IComparable out of the box. Say I want to return products that code less than a given price? Money has to implement IComparable for that to work.
3. Their comparison semantics are lacking especially when the value object contains some sort of collection. Some times we don’t want to use all the values for comparison.
I came across a lib that provides a full fledged ValueObject class that provides all this plumberinf for free.
What are your thoughts on this?
I've switched to using records and I'm not looking back. The drawbacks are negligible most of the time.
The problem with collection is they are reference types, not in the record itself.
@@MilanJovanovicTech Yeah I agree with you on this. Most code bases can live happily with value objects as records.
I didn’t say that the problem is with the record, I said if it contains a reference type (collection) then we need something else.
Thanks
Good video, just one comment- Properties/Collections being accessed directly is indeed an anti-pattern to the point where it has a name- Law of Demeter.
I wasn't aware it had a name 😁
Nicely explained
Thanks a lot!
great content! thanks for sharing!
Glad you enjoyed it!
Hi, Milan. Thanks for your great work. It would be nice if you make videos about ef core. Targeting more deep view on how it works. Like when it creates database connection etc.
I have quite a few EF Core videos already
Thanks for your great effort
Don't mention it
Thx for great explanation. However maybe unpopular opinion over here from practices you can achieve great things even with ’anemic models’ even in pretty big systems if your resource accessor layer has the well defined operations around atomic business verbs.
I don't think it's unpopular opinion, rather just a different approach to implementing a solution. Both get the job done :)
Good explanation 👍
Thanks 🙂
How to work with rich model Order and database? There should be some anemic model in the middle?
You can map it to the DB directly with an ORM like EF Core
@@MilanJovanovicTech yeah but how do you load an order from the database?
@@Ree1BigChris I'll show that in a future video, since I see it's causing confusion 😁
It’s confusing because we’ll have DTO for Ef core (mappers) n request/response (mappers) I assume you’re heading.
@@MilanJovanovicTech That would be great. I'm always working with ADM and this approach would really improve my codebase. Would love to see full example with EF!
How to you instantiate this model when you load the data from the database if the constructor is private? You cannot really call "create()" as that's not a new entity
In this case EF Core will take care of it, otherwise you'd have to do it manually
@@MilanJovanovicTech by manually, you mean that the constructor should be public or that we should create another static method to instantiate a domain entity from a dataset?
How to work with EF in this case?
Are you going to have another entity class for the database?
It would be nice to see the full workflow where you still have OrderService and you need to have a mapping between your Order class which encapsulates logic and your Order entity class.
How would repository implementation look like?
I'll show that in a future video :)
Hi Milan, thank you very much for your content ! How do you deal with all the warnings Visual Studio shows when working with nullables?
Ignore them 🤣
The best is to make the code pass all of them. In my team we have configured our projects to treat these warnings as errors, so Visual Studio won't build if those are not resolved.
1) Get rid of nulls everywhere
2) Check if something is null before accessing it
Hi Milan! Greetings from Brazil!
Could you make a video about the best way to use DDD (rich domain) with EF CORE? I have two screens that use different attributes but have one constructor.
How can I implement the best select function? For example, for one screen, I need to select only the product ID: context.Product.select(product => product.Id). For another screen, I need to select only the product name: Context.product.select(product => product.Name).
Do you recommend using two constructors in the same class?
I apologize for my poor English.
Your videos are great!
Don't use DDD entities for that query, just return a response model
@@MilanJovanovicTech thank you!
Do we need to have a static method in the rich domain model for creation?
No, there's also the constructor. But I don't like having side effects in constructor (like raising domain events).
Hello Milan,
great video.
I don't understand how you use a rich model to make migrations?
It works just fine, you'll see in Friday's video
@@MilanJovanovicTech thank you so much, looking forward to it 👍I am really learning a lot from your videos
At 4:18 you mentioned that there could be more than one places to create order. Why would one implement it that way isn't that what the OrderService is for? If you need to create an order you inject the order service and call the create method no? Where else or why would you implement the order create somewhere else? Maybe I'm too inexperienced to wrap my head around this. Please can you explain?
I meant more like - creating the Order from different flows:
- Normal flow (checkout)
- Copying an existing order
- Wishlist/waitlist into order
@@MilanJovanovicTech yeah makes sense now thanks for clarifying
if we make the setters and constructors private, will we be able to use Entity framework? doesn't entity framework be able to create the domain instances when we are querying data from database?
Yes, EF Core can use private ctors and setters
@@MilanJovanovicTech thanks for the reply
This is good! 🙂
Thank you :)
What about create method have more parameters and we want use mapster to map dto to model? How is that?
That's fine
Could you explain cancellation tokens? I see them everywhere and don't really understand what they do.
They allow the client to cancel the request, and for the API to propagate that cancellation down the method chain
Simple answer, with anemic model you can't control the object state from one place
Well, you can if all the methods modifying it are in one place
Haven’t you heard of use cases?
What is that?
I strongly desagree with your view. A POCO class like your orde class, should never contain logic, Single responsability Principle, leave the logic to a service. Make testing and abstraction so much easier and organized.
Animic classes is somehting that i always enforce in my teams
That's the debate between a transaction script and a domain model