before we start with the obvious rethink your aggregate boundaries I feel there are use cases where this is actually happening.
Let’s take an eshop web app as an example - we have the catalog and the inventory management contexts.
But for the user convenience when creating a new product there is an option to immediately set the stock quantities.
So one action now represents a CreateProductCommand as well as a CreateInventoryItemCommand.
For obvious reasons those 2 live in separate bounded contexts one focusing on the catalog and one the actual inventory for a product thus product and inventory are 2 AR.
What is the correct way to handle this scenario ?
We have the following options
- create the 2 aggregate roots in one command handler - but this is not a good practice
- create a saga. here I wonder how to deliver the required information to the saga - it would start on the CreateProductCommand but in order to issue the CreateInventoryItemCommand it has to recieve the data for that.
what means we would need to apply an ProductInventoryCreated event to pass the required data further to the saga.
- create an API service between the UI and the command handlers that will take the incoming request and submit 2 commands. it has to cope with errors when one command fails etc.