[Axon 3] Distributed Command Bus use cases


I’m currently evaluating the options to leverage the distributed command bus for a new project.

As far as I can see in the Axon Bank example, you use it to horizontally scale the same Axon Application, i.e Axon Bank, meaning that you could define which instance will handle the Command X and so on.

My use case is a bit different, and I wonder if the solutions I first think about are valid :

I currently have an Spring boot application whose modules are more or less split like in Axon Bank (core, core-api, web, and query). Everything is therefore packaged in the same FAT jar, without distributing the query part, but it’s pretty straightforward to change it if needed as the the modules are clearly separated.

Now, I would like to have another application, a CLI to be precise, what would interact with this Spring Boot Application.

I can see three options :

  1. Let the Spring Boot Application expose a REST API that dispatches the relevant command afterwards.
  2. Make this CLI application a lightweight Axon application, that would rely on the distributed command bus to transparently dispatch commands without having any command handlers on its own. Basically this CLI is used to import some existing data (CSV).
  3. Let the CLI publish events to a broker and have a listener on the Spring Boot Application that would fire the corresponding commands (creating the aggregate from the existing data).

Both are very close in terms of data flows, but acccording to your experience, is the distributed command bus a good fit for such cases ?

I m currently deploying these modules in a Docker swarm, and leveraging the built-in service discovery would eliminate the need of Consul/Eureka/…, but I guess I would have to configure a specific CommandBus connector.

Thank you for your insights,


Hi Jerome,

I’ve mostly taken the route to use the Distributed Command Bus set up to horizontally scale your application, but based on my knowledge of the internals I’m very sure you can also use it for the second solution you’re describing.

To give some insight in the internals: when starting up your Axon application, it will collect all the @CommandHandler annotated functions it can find and subscribe those to the Command Bus, or Distributed Command Bus I’ve you’re using it.

In your second scenario, you’ll thus have an application with a Distributed Command Bus, with not local Command Handlers subscribed to it.

It will however check if there are other nodes in the system which can handle the command it’s trying to publish, which would thus push any published commands on your lightweight CLI Axon application to your other Spring-Boot-well-partitioned-Axon-application.

So concluding, my hunch would be that the Distributed Command Bus is a fine fit for this.

Any other insights are much appreciated of course.

Hope this helps you out Jerome!



Thank you Steven for your valuable input !

I’m still experimenting this solution, but another key point is driving me towards the third solution (import from the CSV, and publish some meaningful events to the MQ). I would like to remove the temporal coupling between my CLI and the Axon application. By that, I mean that the users should be able to initiate the import process even if my application is down ( this condition will especially be true during the early stage of this project, as the CLI will be provided to the key user right at the beginning while the Axon application is still under development).

So basically, I would rely on the messaging infrastructure to publish the transformed data from the import and the Axon application would handle them asynchronously at its own pace by consuming them from a dedicated queue.

Nevertheless, it’s interesting to keep in mind the architectural alternative we discussed together to implement some other use cases later on.