Problem statement
In the real world, we have the Entities Assets (Images, Videos, Documents) and Collections (a set of Assets). Now, both these entities can have Categories (and a bunch shared properties more).
We are unsure how to model this.
Here is the current approach:
A) In an AssetService
the Asset
entity can have 1:n categories. For this matter, a CategoryService
has an Asset
Projection, a Category
entity and a relational table AssetCategory
. So far, so good. But now, we find that also another entity (Collections
) can have 1:n Categories
. How do we model several entites can have a category?. In fact, we are also concerned about:
- in the future more entites (like Asset and Collection) can have Category.
- in the future more entities (like Category) could be shared by other entities.
Solutions
B) We can project the Category
into the other services that have a Category
.
Pro: seems clean to have only one shared Category entity
Con: relation of Asset or Collection to Category is moved to the bounded context of AssetService/CollectionService
C) we can also create some sort of "Aggregate" for all entities that have a Category
and merge them in a service and use that as projection to the CategoryService
.
Pro: The service Asset
, Collection
and Category
are in itself quite simple
Con: for every upcoming new entity and combination of things that are shared we need a dedicated Aggregate
D) we can move two projections to CategoryService and relate Category to both.
Pro: Asset and Collection service are quite clean
Con: if more entities are having Categories, a lot of projections are in CategoryService
E) we could of course also create a separate Category
entity for Asset
and Collection
, but they are actually the same Category
from a user-perspective. So, there would be alot of mirroring without a real cause.
No Diagram for E) necessary
Side notes
- we are expecting
- 100 Mio Assets
- 10 Mio Categories
- 10 Mio Collections
- common read queries (like, "give me all Assests and Collections with Category x") will be hanled with a denormalized datasource like Elastic Search