Hi,
I was wondering whether it would be considered bad practice to use an aggregate identifier across a service in another aggregate which shares that they are two aggregates revolving about the same identifiable entity.
The problem I am currently having is that we want to split some logic (bounded context if you so will) into a different service as the one originally creating the aggregate.
In general, this seems to work, as when I send a Command within the second service, it is picked up and updates its state. As I can use EventSourcingHandler to also use Events created in the other service to manipulate its state, I get state information from a source applied by another service.
I was worried that the snapshot mechanism would works against me, but apparently it is smart enough to store snapshots separately as long as I make sure the aggregate “type” name is not the same.
So far, so good, the only thing that’s a smell for me is that the second aggregate does not have (needs) an initial constructor CommandHandler, as the creation is done in the other aggregate.
So, am I going against the way axon framework intends aggregates to be used, or is this a viable use case?
The case for why I tried to split is that we wanted to separate the base logic (creation of the aggregate, in this case a vehicle) from the logic that happens and is handled in a different bounded context (transfers from and to a construction site). As I cannot save a creation event (CommandHandler in the constructor) for the same aggregate identifier twice, I could not separate the two states completely.
So my only options right now would be what I presented above, or use the creation of the second aggregate to set a different aggregateId, but also add internally the aggregateId of the first aggregate to allow for events to be published with the aggregateId of the first as a reference Id. This would I would have to keep a projection to map back and forth between the two identifiers, which also does not look to good.
Thanks in advance,
Lars Karschen
