Introduction:
The framework was first released in 2010 as a pure open source CQRS/ES framework. The framework has significantly evolved over the past years and in addition to the core, the framework offers a server option that includes an Event Store and an Event Router. Axon’s core framework and the server abstract the complex infrastructural concerns required in implementing CQRS/ES patterns and help enterprise developers focus only on the business logic. The icing on the cake is that it adopts DDD as the fundamental building block for building applications. With the recent push among enterprises to adopt a microservices architectural style, Axon’s approach of combining DDD and CQRS/ES patterns provides a robust and feature-complete solution for customers to build event-driven microservices.
Axon Components:
Axon provides the following components:
• Axon Framework, Domain Model – A core framework that helps you build a domain model centered on DDD, Event Sourcing, and CQRSpatterns
• Axon Framework, Dispatch Model – Logical infrastructure to support the domain model mentioned earlier, that is, the routing and coordination of commands and queries that deal with the state of the Domain Model
• Axon Server – Physical infrastructure to support the Domain/Dispatch Model mentioned earlier.
Axon Framework Domain Model Components
Aggregates:
In Axon, Aggregates are implemented as regular POJOs which contain states and methods to alter that state. The POJOs are marked with a Stereotype Annotation (@Aggregate) to specify them as Aggregates.
In addition, Axon provides support for Aggregate Identification/Command Handling (change of state) within the Aggregates and loading of these Aggregates from an Event Store (Event Sourcing). The support is provided utilizing specific Stereotype Annotations (@AggregateIdentifier, @CommandHandler, @EventSourcingHandler).
Commands/Command Handlers:
Commands carry the intent to change the state of the Aggregates within the various Bounded Contexts. Command Handlers are routines that are placed in an aggregate; and they take a specific Command, that is, the state change intent as the main input. While the actual Command classes are implemented as regular POJOs, and the Command Handler support is provided via stereotype annotations (@CommandHandler) which are placed on the Aggregate. Axon also supports placing of these commands in an external class (External Command Handler) in case it is required.
Events/Event Handlers:
The processing of Commands on Aggregates always results in the generation of Events. Events notify the change of state of an Aggregate within the Bounded Context to interested subscribers. Consumption of Events is handled via “Event Handlers” that subscribe to the events they are interested in. Axon provides a stereotype annotation “@EventHandler” which is placed on routines within regular POJOs and enables the consumption and subsequent processing of events.
Query Handlers:
Queries carry the intent to retrieve the state of aggregates within our Bounded Contexts. Queries in Axon are handled by Query Handlers via the @QueryHandler annotation which is placed on regular POJOs. Query Handlers rely on the Read Model/Projection data storage to retrieve the Aggregate state. They use traditional frameworks (e.g., Spring Data, JPA) to execute the Query requests.
Sagas:
The Axon Framework provides first-class support for both Choreography-Based Sagas and Orchestration-based Sagas. Choreography-based sagas are achieved through regular Event Handlers provided by the Axon Framework. The Axon Framework provides a comprehensive implementation to support Orchestration-based Sagas.
This includes the following:
• Lifecycle Management (Start/End Sagas via corresponding annotations, Saga Managers)
• Event Handling (via @SagaEventHandler annotation)
• Saga state storage with support for multiple implementations (JDBC, Mongo, etc.)
• Association Management across multiple services
• Deadline Handling.
Axon Dispatch Model Components
Command Bus:
Commands which are sent to the Bounded Context need to be processed by Command Handlers. The Command Bus/Command Gateway helps in dispatching Commands to their corresponding Command Handlers for processing.
To expand
- CommandBus – An Axon infrastructure component that routes the Command to the corresponding CommandHandler.
- CommandGateway – An Axon infrastructure utility component that is a wrapper around the CommandBus. Utilizing the CommandBus requires us to create repeatable code for every command dispatching (e.g., CommandMessage creation, CommandCallback routines). Using the CommandGateway helps in eliminating a lot of the boilerplate code.
Axon provides multiple implementations of the CommandBus:
• SimpleCommandBus
• AxonServerCommandBus
• AsynchronousCommandBus
• DisruptorCommmandBus
• DistributedCommandBus
• RecordingCommandBus
Query Bus:
Queries that are sent to the Bounded Context need to be processed by Query Handlers. The Query Bus/Query Gateway helps in dispatching Queries to their corresponding Query Handlers for processing:
• QueryBus – An Axon infrastructure component that routes the Query to the corresponding QueryHandler.
• QueryGateway – An Axon infrastructure utility component that is a wrapper around the QueryBus. Utilizing the QueryGateway eliminates the boilerplate code.
Axon provides multiple implementations of the Query Bus:
• SimpleQueryBus
• AxonServerQueryBus
Event Bus:
Event Bus is the mechanism that receives events from Command Handlers and dispatches them to the corresponding Event Handlers which could be any other Bounded Context is interested in that event. Axon provides three implementations of the Event Bus:
• AxonServerEventStore
• EmbeddedEventStore
• SimpleEventBus
Sagas:
The Axon Framework provides a component SagaManager for this. Similarly, orchestration-based sagas require state storage to store and retrieve Saga instances. There are various storage implementations that the Axon Framework supports (JPA, In-Memory, JDBC, and Mongo, Axon Server). For our implementation, we will use the Saga storage provided by Axon Server itself. Axon applies sensible defaults here too and will automatically configure a Saga Manager and Axon Server as the state storage mechanism when we create a Saga.
Axon Infrastructure Components: Axon Server:
Axon Server provides the physical infrastructure necessary to support the Dispatch Model. Broadly, Axon Server has two main components:
• An Event Store based on H2 (used for storage of configuration) and a file system (used for storage of event data)
• A Messaging Router for the Events flowing through the system Here is a quick summary of its features:
• Built-in Messaging Router with support for advanced messaging patterns (Sticky Command Routing, Message Throttling, QoS)
• Purpose-built Event Store with an inbuilt Database (H2)
• High Availability/Scalability Capabilities (Clustering)
• Security Controls
• UI Console
• Monitoring/Metrics Capabilities
• Data Management Capabilities (Backup, Tuning, Versioning)
Axon Server is built using Spring Boot and is distributed as a regular JAR file. It utilizes its own file-system-based storage engine as the event store database and is available for download at www.axoniq.io.
Command to bring up the Axon server
java -jar axonserver-4.1.2.jar
This brings up Axon Server, and its console can be accessed at http://localhost:8024.