Relationship table modeling in CQRS/ES.

Hi All,

I created three aggregate.

Catalog Aggregate - Store information of Catalog.

Category Aggregate - Store information of product categories

CatalogCatagory - hold the relationship between Catalog and Category (Id of both aggregate).

The relationship between two aggregate is many to many. A Catalog have any no of categories and Categories have any no of Catalog. So I decided to create a new aggregate CatalogCategory aggregate (like in rdms relationship table), which hold the Id of both aggregate and some other properties.

In business- A user can create Catalog and Category separately. And map Catalog with Category.

Example -

User create a new Catalog-A and then create a new Category-2. After that user map Catalog-A with Category-1 (old one) and Category-2 or map Category-1 with Catalog-A and Catalog-B (old one).

Is this the correct way to hold the relationship between two aggregate in case of many to many relationship or any other options ?

Hi Ashwani,

Whether “this is the correct way” is very much dependent on the domain you are in, and the problem you are trying to solve in that domain.
The answer “it depends” typically prevails with questions like these as none of us here are domain experts of the application you are working with.

Regardless, I think I am able to give some guidelines to clarify things.
As the title states, you want to employ CQRS and Event Sourcing, where I am going to focus on the former for my answer.
When doing CQRS you are essentially creating two distinct models tailored towards their use case: the command model and the query model.

The Command Model is in charge of handling commands and maintaining the consistency boundary by validating your business logic.
The Query Model is there to serve the information of your application as best as possible to suit the use case.

Now, when you are talking about Aggregates, I am assuming you are talking about the @Aggregate annotated classes you can create in Axon.
Note that these are regarded as the Command Model which, to reiterate, are there to validate your business logic.

Then let me ask you a question: is there any business validation done on an aggregate called the CatalogCatagory?
As you state, it’s just a container of the association between Catalog and Category.

What do you need this container for? If it’s to provide information, then you are dealing with a Query Model, thus not an @Aggregate annotated class.

You are stating a flow of operations the client would perform:

In business- A user can create Catalog and Category separately. And map Catalog with Category.

Thus, you are mapping a Catalog with a Category.
To me this sounds like a “MapCatalogWithCategoryCommand”/“AssocciateCatalogWithCategoryCommand” which would be handled by the Category aggregate.

The event resulting from that command handler would then be used to update the “CatalogCatagory” query model with the new association to be viewed by the client.

Subsequently this event could be used to send an operation to the Catalog to state it’s associated with a Category.

This is my two cents to the scenario, hope this helps you out!