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

[Gerard Quinn]

I add an event to the domain in my command handler

@CommandHandler
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 ....

public void addUnit(Integer unit) {
    apply(new UnitAdjustmentEvent(this.id, unit));
}

This is applied into the EventStore, persisted through the Repo. I now want to raise an event that takes the new calculated unit and publishes it to my KeyStore.

The calculation is run from the aggregate event source and published to many consumers. 

How best is this achieved, implement an EventStore or inject the command or eventbus onto the aggregate. There are 13 type of events that adjustment the value. 
After each update event into the EventSTore, the new calculated value must be published to the View, which is an cache.

I've implemented EventStoreEngine for Cassandra. A KeyStore using Mongo.

I might push the calculation onto a Queue, that is read by the KeyStore Listener and pushed into Mongo.

Thanks,
Gerry

[Steven van Beelen]

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.

Cheers,

Steven

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gerard Quinn]

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!

Regards,

[Steven van Beelen]

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!

Cheers,

Steven