Axon Framework provides an underlying technology platform to allow building of solutions that utilise the CQRS and Event Sourcing architectural patterns. It combines these with a message bus approach that allows for distribution, location transparency and service redundancy.
In this post, rather than describe Axon Framework in great detail, I just want to focus on the main essence of this framework. More details can be found in the resources section at the end of the post.
The Fundamentals of Axon Framework
Axon Framework is built on an underlying model of distributed message buses. There are three different buses that it supports:
- The Command bus is for sending point-to-point messages from a single client to a single handler for each type of command. Clients can wait on the commands they send to ensure that they have been processed and did not raise an exception.
- The Event bus is for distributing events to multiple subscribers following common publish-subscribe and event streaming approaches. Events are dispatched asynchronously and are at the heart of the Axon Framework.
- The Query bus is for sending messages that expect response data. Typically they are from a single client to a single handler for the query, although there are options for undertaking scatter-gather queries as well. The query mechanism also support streaming and subscription queries for longer-running and periodically updating data.
The Command Model - CQRS with Event Sourcing
Axon Framework combines together the Command Model aspect of CQRS with Event Sourcing for persistence of the domain model state.
At the heart of the command part of the framework is the concept of an Aggregate (taken from the concepts of Domain Driven Design). An aggregate represents the state of a particular entity in the domain (e.g. Customer, Order etc.). The essential behaviour of an aggregate is as follows:
- It receives Commands, via the command bus, instructing the aggregate to apply some change to its state
- Business rules are applied to determine what state changes, if any, are needed
- The determined changes are encapsulated in an Event, which is published via the event bus
- Events are stored in the event store to allow future hydration of the aggregate (and other replay scenarios)
- The Event is also applied to the aggregate so that the in memory version represents the latest state
Active aggregates are maintained in-memory within Axon so that they can respond quickly to new Commands. As needed they are removed from memory and when next referenced, they are rehydrated by replaying the Events that were stored in the event store for that aggregate.
Axon also has a mechanism called Sagas which allow implementation of long-running, stateful, event-driven workflows. These allow coordinating one or more aggregates together to implement a larger business process.
The Query Model - Event Driven CQRS
Axon Framework also provides support for the Query Model aspect of CQRS. This consists of creating specific views that clients can use to access the current state of the system.
The query part of the framework is driven by the Events that are generated by the Command Model. These are used to build the view state that is then retrieved using the query mechanism. The essential behaviour of the query model is as follows:
- Listeners register for Events that they are interested in using to maintain the views
- Events are received, via the event bus, by all the listeners registered for that Event
- Each listener updates one or more views of the system, usually in a database with specific tables for each view being supported (denormalised)
- Clients send Queries, via the query bus, to access information held in a specific view
- Retrieved information is returned to the client over the query bus
Given the above model, it is quite common for some information to appear in multiple different views, based on client use cases. For example there may be a view specific to an API and another for use by a specific UI page. View data can also be used for other purposes, such as to populate and elastic search or populate an externally facing event stream.
The fact that the query model is populated based on Events, ensures there is a very loose coupling between the command and query models. However, this also means that the query model is classed as being eventually consistent. This means that for short periods it may be temporarily behind the state held in the command model, and this is an important consideration for designing systems built using CQRS and Axon Framework.
Summary
From the above we can see that Axon Framework offers an excellent technical platform for implementing a solution based on CQRS and Event Sourcing. The AxonIQ ecosystem also supports a distributed server, that implements the event store and buses as well as various developer support and monitoring tools.
Designing event-based CQRS systems requires some different design thinking than creating a more traditional architecture. For those interested in this area, then the topic of Event Storming is worth more investigation.