Raise Non-Domain Event after apply() to Update KeyStore

I add an event to the domain in my command handler

public void handle(UnitAdjustmentCommand command) throws Exception {
  Aggregate<MyBusinessEntity> entity = repository.load(command.getId());
  entity.execute(aggregateRoot -> aggregateRoot.addUnit(command.getUnit()));


Then in my aggregate ....

MyBusinessEntity ....

Hi Gerry,

First, what’s the ‘KeyStore’ you’re referring too? Not Axon’s ‘TokenStore’ I assume?
Second, I do not fully comprehend what you’re trying to achieve exactly, but I can tell you I’d advice against wiring the EventStore or CommandBus in your Aggregate.
Wiring the CommandBus means you’re gonna publish commands on event sourcing an event, thus meaning you’re gonna lock another aggregate from handling commands; you’d thus introduce a blocking call in handling commands/events in your aggregate, something you should always try to avoid to increase the performance of your Aggregate.

Adding you’re EventStore to me suggest you’re either gonna publish more events or you’re gonna query an event stream. For the first you should always use the ‘AggregateLifecycle.apply()’ function in your aggregate and the latter is again a blocking call as you’re pulling events from a database.

If you want to react on events like your UnitAdjustmentEvent (which I suggest renaming to UnitAdjustedEvent, to point out it has happened), you can simply introduce a class with @EventHandler annotated function for the event you’re interested in.
On handling that event, you can then update the View you’re talking about.

I hope this gives you some insights Gerry.
If I’m however reading your question incorrectly, feel free to clarify.



Thanks Steve,
Apologies, I was off doing other piece of work and only getting back now.

That new event, raised after the apply() in the aggregate, would I raise that through the EventBus? If so, just inject the instance into the aggregate?

What’s your thoughts on the AsynchronousCommandBus or DisruptorCommandBus? I would push that event into command and update the record. The keystore in this instance is mongodb, not a token store.

I here this DisruptorCommandBus is 4 times faster than the default one!


Hi Gerard,

Again a bit puzzled if I’m answering your question correctly here, but here goes.

If you’d want to apply a second event in the Aggregate in an @EventSourcingHandler annotated function, you can simply again call the AggregateLifecycle.apply() function. No need to wire the EventBus manually to publish another event.

And I’d say first try out the AsynchronousCommandBus, as the DisruptorCommandBus it’s plumbing is a bit more intricate then the async solution.
So optimize in steps is what I’m angling for; if the AsynchronousCommandBus does not perform well enough for you, then you can always try out the DisruptorCommandBus.

Hope this helps!