The diagram below is a simplified view of our CQRS/ES application architecture. It’s pretty straightforward thanks to Axon. The basic message flow is user agent REST API request -> send domain command -> handle command -> dispatch domain event -> project event to JSON. The JSON is then read by the API in response to separate REST requests from user agents.
I’m considering deploying the Domain and Projection components together in the same JVM (so a cluster of servers each with domain+projection) instead of using a distributed event bus.
All commands for a given aggregate ID will be sent to the same node. I can then configure an Axon local event bus so that events for a given aggregate ID will be projected in the order that they were dispatched from the domain, right?
What would be the local event bus configuration options to make sure that the projection event handler executes asynchronously? Or is that the responsibility of the event handler itself?
Apart from losing a level of control over balancing the processing load due to combining domain and projection on the same node, are there other factors that would make the a distributed event bus better?
Thanks,
Kevin
Yes, that’s correct. The only true guarantee about ordering is that events originating from the same aggregate are always processed in order.
Your event handlers should be unaware of this. The Processor handling the events (and invoking the annotated handlers) is the place where asynchronous behavior should be implemented/defined. In the SubscribingEventProcessor (default), you can define an EventProcessingStrategy. There are two available implementations: DirectEventProcessingStrategy (default) and AsynchronousEventProcessingStrategy. The latter allows you to handle events asynchronously. Alternatively, you can use the TrackingEventProcessor, which is asynchronous from the publishing thread as well. However, it is not guaranteed that events are handled on the machine that published them (and currently sharding is not supported, only active-passive).
You probably want a combination of local and distributed any way. Within the application, you can choose for SubscribingEventProcessors, while you also publish your events to AMQP for other applications/components to use.
Thanks, Allard. I’m using Axon 2, but was able to get the local event bus ordering I wanted using the ClusteringEventBus and an AsynchronousCluster with the SequentialPerAggregatePolicy. Really nice how easily I can switch between projecting events locally and projecting events on another node with just a bit of configuration.
The basic message flow is user agent REST API request -> send domain command -> handle command -> dispatch domain event -> project event to JSON. The JSON is then read by the API in response to separate REST requests from user agents.