Using the method @TargetAggregateIdentifier & @AggregateIdentifier implementation to create a composite identifier

Architectural Concepts
1

Hi, so I have updated our current implementation of the axon framework to start using a composite aggregate identifier instead of just using a single field as we have started to receive inputs with the same fooId but just a new versionNumber.

@AggregateIdentifier
private String getAggregateIdentifier() {
	return (null != versionNumber) ? (fooId+ "V" + versionNumber) : fooId;
}

We are a pass through application, so the fooId & versionNumber isn’t something in our control, this data is part of the input into our application. We are using a repository solution to store the event in our sql database and using rabbitmq to direct the events to the projection & to the correct queues.

This solution we have implemented works, but I was just wondering if anyone has implemented something cleaner. I came across this post by @Steven_van_Beelen where he mentioned that we can implement our own version of the EventStorageEngine and add additional columns to the db. Are there any github practice references for this that I could refer to?

Thanks.

2

I’d wager deciding whether there’s a cleaner approach to the problem you are having requires us to know the exact solution you have implemented. Unless all the is to it is the snippet you’ve shared? If not, it might be a good idea to share a bit more on what you’ve done in the Commands for routing and the Aggregate for being identifiable.

When it comes to the post you came across, I wouldn’t know of any sample projects which do this. I was purely required to do this direct at a client several years back. That custom piece of code is obviously not shared but added they’ve moved away from that solution towards Axon Server. It is good to now that any solution you’d craft with additional columns is not something you can migrate to Axon Server. Not as a distinct column at least, since Axon Server does not allow you that level of freedom.

Lastly, it would be good to note that this additional column was purely there as a convenience for querying events for debugging. The aggregateId wasn’t used outside of the application, so we were required to use fooId to retrieve all the events. It simply was a more efficient solution than doing a SQL with CONTAINS in it.

1 Like