AggregateClassA
{
String : id,
List : ClassBIdList
}
ClassB is an aggregate from another service
Now lets say, I receive a rest request to update all records of my AggregateClassA where ClassBIdList contains “OldId” and replace “OldId” with “NewId” for all those aggregates.
Is there a good way to identify and load all aggregates where “OldId” exists in ClassBIdList. I am currently calling my state database to identify all these records.
Does Axon provide API to query domain event repository based on attributes other than id in the payload?
in a pure CQRS (or even DDD) approach, commands will always target a single aggregate at a time. The scenario you describe is basically a batch scenario, which consists of a query (find all aggregates with a specific state) and then a number of commands (update each of those aggregates).
The reason for this approach, is that the aggregate itself is, first of all, a consistency boundary. It is responsible for maintaining a valid state at all times. Traditional systems don’t take this approach, but instead allow services to update data directly when they see fit.
So in your case, there is a mechanism (which could be triggered by a command) that would execute a query to locate all relevant aggregates and then send a command to each of the individual aggregates to remove the “oldId”.
Thanks Allard. I agree that on the command side each command should update only one aggregate.
But on the query side to find all these relevant aggregates, is the recommended approach to extend my event store mongo repository interface to implement a custom query method to identify aggregates (i believe the default implementation only supports querying event store by aggregate id) or use my state cache which might be stale.
the “query” to get all aggregates related to a specific “oldId” should be done against a query model, via a repository dedicated to query models.
A separate model doesn’t necessarily mean it is eventually consistent. That’s a choice one could make. If the model is small, and not very frequently updated (otherwise it could be a big performance impact), you can have it updated in the same transaction as the command handling. Simply make sure the Event Handlers are assigned to a Subscribing Processor. Since this model is highly coupled to the Command Handling component, I’d recommend putting it in the same module/package.
In essence, this is what CQRS is mainly about: create models that are really focused on the task at hand. Axon gives you plenty of choices in how you want to deal with the consistency of these models.