Axon is a lightweight framework, implemented as a Java Spring Boot microservices application, built in independent Maven projects, and distributed as an executable JAR; it is based on the Command Query Responsibility Segregation (CQRS) principles. The main concept here is that you can use a different data model for update operations (update or insert) and read operations.

Axon uses two different channels to exchange information between services:

• A command bus
• An event bus

The command bus is the actor that has the target receive the command object, containing all of the data relative to the operation to execute; it forwards it to the command handler. The command handler executes the operation (and the business methods) specified by the command object.

The result of this operation is the generation of the domain events that form the domain model.

The event bus dispatches events, synchronously or asynchronously, to event listeners, which execute the operations (for example, to update a data source or send a message to an external system).

The command handlers are completely unaware of the components that are interested in the changes they make; in this way, you are able to build a loosely coupled architecture.

Axon uses two different implementations for the command bus—JGroups Connector and Spring Cloud Connector, based on the Netflix Eureka Discovery client and Eureka Server combination.

For the event bus, the framework uses RabbitMQ, an external open source messaging system that supports multiple messaging protocols; in the Axon implementation, the event bus is built on top of the Advanced Message Queuing Protocol (AMQP).

Axon is a very powerful framework, but if you want to use it to handle the transactions in your system, you must be aware of the following challenges:

• Maintenance of the saga life cycle: Axon provides only the implementation to start and stop the saga execution. The handling of some important aspects of the saga pattern is up to the developer—for example, the invocation of participants, the relative collection of responses to define the final state of the transaction or the handling of the compensations actions, in order to recover the original data state after a failure, are delegate to the developer since the framework implements the communication between the participants of the saga only through events. This implementation model of the saga specification could become a potential bottleneck of the saga pattern's maintenance.
• CQRS restrictions: In Axon, the sagas are only a specialized type of event listener: this implementation model could be too restrictive in an environment that doesn't use the CQRS pattern.