Search code examples
database-designdomain-driven-designddd-repositories

Generalize common entities in DDD


there are some common entities and value objects in my system and I just wanna to generalize them to do better management.

I'm developing a large scale application with different kinds of aggregates and contexts and I map the domain aggregates via fluent nhibernate. I have different kinds of tag in my system:

ProductTag
BlogTag
NewsTag 

and also have the same story about category, comment and... now I just want to make a kind of generalization in data base to have the list of all tags, categories and comments ... now is it a good idea to create an aggregate for each of them (Tag, category, ...) and have a whole table for them in data base and then create join between other tags or categories??(I mean by other is productTag, BlogTag ,...)

I've all of these tags as value object, how can I have an instance of a value object in another aggregate root??(for example productTag(VO) in Tag(aggregate Root)).

I need to have better management on these entities I think the best way of handling it is creating whole aggregate for each of them, what do you think??


Solution

  • after discussing with one of my colleagues I found that there is no need to generalize these entities and there are lot's of differences between domain concern and database concern. first of all it's impossible to make have a value object as a reference in another aggregate root(aggregate roots could have a reference of other aggregate roots). I just wanted to solve a database concern via domain driven design concepts, as @StevePuder also mentioned above there is no need to do something like this if you don't need to list them in UI. although I need to list the list of product tag, product category, blog tags and ... in UI but I don't need to collaborate all them separately in another table in sql server! to do that I can simply create a query service to fetch the product tags and ... so, there is no need to do a cost effective and also wrong things just because for a database concern to make the query operation simpler!