Generalize common entities in DDD

Question

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??

Answer 1

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!

Answer 2

...now I just want to make a kind of generalization in data base to have the list of all tags, categories and comments...

Correct me if I'm wrong, but I think you're trying to solve a pure UI concern via the database. Do you really need the list of all tags/categories/comments inside your domain model or do you only list them somewhere in the UI? Do you want wo introduce the additional aggregate roots only to be able to query them from a repository? You should avoid enriching your domain model solely for the sake of the user interface or your persistence mechanism.

However, if there really is a need for a common interface for these value objects (e.g. when business rules need to know all tags in the system), then this concept should be reflected within your domain model and not just in the database.

Personally I'd favour an implementation based on domain events. Each aggregate would raise it's own event (ProductTaggedEvent, BlogTaggedEvent, NewsCommentedEvent,...) containing all necessary information about the concrete value object in the context of it's aggregate. A separate component (another aggregate or even bounded context) would listen to these events and create a specialized model containing all the tags/categories/comments in a structure that can be queried easily. It could be persisted in the same database along with your other aggregates or even in a another repository with a completely different storage mechanism (as it is usually done by the most CQRS implementations). Anyway, there would be no need to generalize anything if you create a second model/concept specialized for the needs of e.g. your user interface.