Hello,
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,
Cheers,
Jerome