DDD in .NET Apps: Entities and Value Objects - A Comprehensive Guide

When we design our domain model, according to Domain-Driven Design (DDD), everything is entity and value object. In this video I go into an in depth explanation of what DDD entities and value objects are. Then I go into some more practical aspects and show some strategies that we could use to implement DDD entities and value objects in .NET applications.
#dotnet #ddd #softwarearchitecture
Join this channel to get source code access and other perks:
/ @codewrinkles
Mentioned videos:
1. Bounded contexts in DDD: • Unlocking Bounded Cont...
2. Equality types in C# and #dotnet: • The Dangers of Equalit...
Contents:
1. Intro: 00:00
2. What are entities? 00:47
3. What are value objects? 02:29
4. Why is my domain model not DDD compliant? 05:41
5. What is the shared kernel? 08:26
6. The entity base class: 09:29
7. The value object base class: 13:46
8. Refactoring to entities and value objects: 18:04
9. The value object challenges: 21:46
10. Using records as value objects: 23:44
11. Conclusions: 28:34

[@uzayrsyed6293]

Great video as always! Looking forward for the EF Core video which shows mapping DDD objects like entities and value objects to database

[@TH2theEO]

Your channel is amazing! 🎉🎉🎉

[@user-bx7xi7bu9k]

the best explanation of Value Objects ever found, I will sleep less stupid tonight 🥳 thx a lot

[@Codewrinkles]

I'm soooo glad you find it useful.

[@danielegiovanetti9258]

Very useful video. Thanks so much for sharing this topic

[@Codewrinkles]

My pleasure

[@Fikusiklol]

Hello there! First of all thanks for the effort! Your override for == operator might throw an Exception if first Entity is null. I would suggest using Equals(obj1, obj2) operator there :)

[@VinuP2023]

Useful video. Thanks much :)

[@Codewrinkles]

Glad to hear that!

[@Babs42]

Don't they technically call the Entity base class and common interfaces "Seedwork" as opposed to a Shared Kernel BC with code and data shared by multiple bounded contexts (it's technically a context mapping type)?

[@Tamer_Ali]

Hi Mr.Dan, I have a question about saving attachments/Media "Images and files". is it better to create a single table with fields "ID, FileOriginalName, FileNewName, ContentType, Notes,..." and use the ID to the parent tables?

[@Codewrinkles]

That is for sure one option. Another one would be to have for each entity a dedicated table for file information, so you'd have tables like ProfilePhotos, PostPhotos and so on. In my opinion there is no silver bullet solution here. It all depends on how your application is generally working with files, if it uses a lot of files or not so much and so on.

[@OlehYevseienko]

🎉🎉🎉

[@rpo3ge]

Hi @Codewrinkles, one question around the base valueobject class, in its current setup would the equality be handled correctly on a collection property? The code only does this.property.Equals(another.Property) unsure if Equals would work with collections, so how can you check type check that? Thank you for the great content on the topic.

[@Codewrinkles]

I'm not sure exactly what you are referring to. When it comes to the value object itself, equality is always calculated with reference to the value object itself. Checking two collections for equality is a total different thing and it's implemented differently in each type that implements ICollection.

[@Codewrinkles]

In a real app you'd never check two collections for equality. And if you do, it would use the .NET implementation for that specific collection type. If you create your custom collection class that implements ICollection, you would need to implement a custom equality check on the collection class itself. Doesn't really have anything to do with the concept of value objects.

[@rpo3ge]

Thanks for getting back to me. Say Category has a property of type List AvailableCategories or something like that, I was interested if there is a case of having a collection in a value object and how the equality works. As the current base class seems to handle only primitive types in it’s generic configuration. I.e. how would you do .SequenceEqual() Hope I am making sense!

[@Codewrinkles]

you would also yield return elements from the collection. But once again, it totally depends on how you would like to implement equality and what equality means. If you yield return the appropriate items, then equality check will work. It's not a necessity to yield return just properties.

[@Ronaldos267]

First of all, I would like to admit that I learnt a lot from your awesome videos and I keep learning as well. I would also like to admit that I am also learning a lot about DDD from your videos. I have a query - in my opinion, in a big eCommerce system, category can also be a separate bounded context, as categories can also be created, updated, deleted, etc. So we can also create it as an aggregate root/entity. Please correct if I am wrong

[@Codewrinkles]

Thank you very much for your nice feedback. Bounded contexts are used in DDD to define areas of coherent business behavior. According to DDD, bouunded contexts are not necessarily what we define as developers. As Developers we need to understand the business and the bounded contexts it is operating upon. In this paradigm, CRUD logic is never considered business logic and therefore I don't think that categories in an eCommerce system would be a dedicated bounded context.

[@Ronaldos267]

@@Codewrinkles thank you for your prompt reply. It means if a new product belonging to a new category to be added in the system then it would all be persisted through the product aggregate. But suppose we want to show all the categories as well on the GUI. In this case, we will have to go through all the products to just find out the categories in the system because categories an only be accessed through the aggregate root.

[@Codewrinkles]

I think one of the common misconceptions in DDD modeling is to think about our aggregates and entities in terms of database tables. That's from my point of view the wrong way to try to understand DDD. DDD is about modeling behavior. This overlaps with the tendency to think about everyting in terms of CRUD. These two are the main reasons why DDD fails in most of the attempts. In a real eCommer system modeled around DDD (at least in my opinion and following Evans' guidelines), creating a product is a simple CRUD operation that doesn't need to me modeled in a DDD way. It's just regular transaction script. Further, when you have a create product form, you would have just a few fields like Name and description. Then you would go through a stepper to enhance the product with different functionalities. All these steps in the stepper correspond most probably to different bounded contexts. In this process you would have to choose a category. If the category does not exist, you would have a create new category button that just creates a category the CRUD way. If you take a moment to analyze how Amazon for instance is build and also look at the network in your dev tools you'd see that what you mentioned is not a single process. Here's a video from @codeopinion that illustrates this better: kzbin.info/www/bejne/Zna0dJZ3gdlsecU

[@zutafe]

Wait for your next video

[@Codewrinkles]

Coming in around one week :)

[@rpo3ge]

Hi @Codewrinkles, is the video where you talk about how to use EF Core for persisting the discussed Entities and ValueObjects dynamic, I didn't manage to find it. Thank you

[@Codewrinkles]

It's not there yet. I will publish it on Thursday.

[@rpo3ge]

@@Codewrinklesno rush, thank you, appreciate the effort!

[@TreeLuvBurdpu]

I'm still stuck on the river. So, when Hericlitus talked about, for instance the Nile River, he was referring to the volume of water that was in the Nile River channel at that moment? Then, a day later he world have to refer to the Nile water volume of that day as "Nile-water volume v1.0.1” or something? That's not what any normal humans mean when they refer to a river, many of which have lasted for tens of millions of years.

[@borisnicolai9736]

Why do create for each bounded context its own solution and not just projects in one solution? Is there any specific reason? Thanks

[@Codewrinkles]

Usually when you do full DDD you would also go for microservice and each bounded context would be a separate microservice. I wanted to make this total separation clear.

[@borisnicolai9736]

Thanks for the (fast!!) response

[@nurzhanme]

Entity also should be abstract, right? Also you don't need "id" property in Product class

[@Codewrinkles]

Sure, you can make Entity abstract. It's probably even better.

[@semen083]

Maybe you don't need "id" property in Product class, because it already exist in base class?

[@Codewrinkles]

You are right about that.

[@mdsojibhosen3041]

Please give me the souce code link

[@Codewrinkles]

Ambassador Members have access to the source code. You'll be able to get it and use it after you become a member.

[@mdsojibhosen3041]

@@Codewrinkles How to become a ambassador member.I can't find any link!