Hi Team,
Our team is using Mongo as our event store, we recently upgraded from Axon 2 to Axon 4 and all seemed well until we ran into one issue that has left us questioning the design in Axon 4. We have a service that handles one event, loops through it’s data, and dispatches the same command multiple times with minor changes in the data using commandGateway.sendAndWait(). The weird thing we’re seeing is when we query the domainevents collection in mongo, the data appears like this:
{
"aggregateIdentifier": "ID_2",
"eventIdentifier": "EVENT_2,
"events": [
{
"aggregateIdentifier": "ID_1",
"eventIdentifier": "EVENT_1,
...
},
{
"aggregateIdentifier": "ID_2",
"eventIdentifier": "EVENT_2,
...
}
]
}
We are using the DocumentPerCommitStrategy, but in the earlier implementation, it seemed the collection made sure to separate the events by aggregateId; however, as we can see with Axon 4, it’s storing events with completely different aggregate id’s under the same aggregate. Is that intended? We planned to implement our own DocumentPerCommitStrategy that ensures commits are split by aggregate id’s but left us wondering if we’re missing something.
We did notice the Unit of Work appears to batch events that have nothing to do with the intended aggregate instance. Should I assume the Unit of Work is just batching all applied events within a current thread regardless of whether they’re part of the same aggregate instance?