I'm soooo glad you find it useful.

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.

@@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.

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: kzfaq.info/get/bejne/ZquBdsZysdqdc5c.html

My pleasure

Glad to hear that!

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.

Thanks for the (fast!!) response

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.

Coming in around one week :)

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.

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.

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!

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.

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

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

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

You are right about that.

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

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