Exploring CQRS Architecture with Axon Framework: Introduction

This is a first post in a series of posts that explores the CQRS architecture with Axon Framework.

The aim is to first understand what CQRS is from a conceptual/architectural standpoint and then explore what building blocks the Axon Framework provides that can help in building applications following the CQRS pattern.

The posts in this series include:

1. Exploring CQRS with Axon Framework: The Command, Command Bus and Command Handling Components
2. Exploring CQRS with Axon Framework: Overview of Some DDD concepts: Entity.
3. Exploring CQRS with Axon Framework: Building the Entity, Aggregate, Aggregate Root and Repository components
4. Exploring CQRS with Axon Framework: Introducing Domain Events and Event Handling.
5. Exploring CQRS with Axon Framework: Applying Event Sourcing.
6. Exploring CQRS with Axon Framework: Overview of the Testing infrastructure.
7. Exploring CQRS with Axon Framework: Closing thoughts.

What is CQRS

CQRS is a way of building software systems that stresses separating the part of your application that changes the state of the application and the part that queries the state of the application. We expand more on this in the section: “A bird’s eye view of CQRS”.

What is Axon Framework

The Axon Framework tagline says: “CQRS framework for Java”. I guess that pretty much sums it up? Axon Framework describes itself as a framework that helps build scalable, extensible and maintainable applications by supporting developers to apply the Command Query Responsibility Segregation (CQRS) architectural pattern.  It does so by providing implementations of the most important building blocks, such as aggregates, repositories and event buses (the dispatching mechanism for events)

You can read more about this and the background to Axon Framework here.

Before we start looking at what building blocks Axon Framework provides for building CQRS applications, let us first have an overview of what CQRS is about. If you are already familiar with CQRS, and just want to see how the Axon Framework can help you, then feel free to jump to The Command, Command Bus and Command Handling Components

A bird’s eye view of CQRS

I like to think of CQRS as a cumbersome acronym for a simple concept, which is, have the “write” part of an application distinctly separate from the “read’ part of an application.

If you look at the definition of the acronym, that is what it is basically saying: Command (the write portion), Query (the read portion) Responsibility Segregation (should be separated).

For example if i have such a class foo

public class Foo {

// changes state
private void makeFoo() {
}

// reads state
private Foo getFoo() {
}

The functional responsibility of changing state and reading state are separated into two methods but they are still very much tied together as they exist in the same class making it impossible to distinctly separate them.

Moving the getFoo() to another class and makeFoo() to another achieves some separation: CQRS is about achieving these kind of separation on the infrastructure level and not just on class level.

That is all to it...

The exact way to achieve this separation is left open and not specified in the CQRS definition. 

But we would notice that by the very nature of this definition stipulated by CQRS, loose coupling ends up being intrinsic to the very idea of CQRS. it is no surprise then, that we often find component based and event/message driven design as the approach usually used to implement CQRS.

In some quarters/discussion, CQRS is not even seen as an “Architecture” but a “Pattern”. A pattern, or approach, which, when followed can open up the space to applying different other architecture to aid implementation.

This, in my own opinion, adds to the muddling of the water when it comes to approaching CQRS for the first time. For instance, I can wager that as soon as you start dabbling into CQRS, you will almost immediately come into contact with concepts like event sourcing, eventual consistency, messages and actors etc. Which ends up opaquing the idea represented by CQRS.

For example event sourcing always, almost, pop up when CQRS is mentioned, so much so you will think it is technically part of what CQRS is, although that is not the case. You can have a CQRS system without event sourcing!

Once I made this clarification, things became clearer: CQRS is simple, it only says writes and reads should be separated. But because of the loosely coupling this opens up for us, component based approaches, powered by messages has become one of the most popular way of achieving CQRS.

The next question is what are the components that comprises your typical CQRS setup? Or more accurately, the components that the Axon framework provides infrastructure for.

To answer that, we will use comparison with a layered architecture.

Layered Architecture vs Component Based Architecture.

In Layered architecture, the parts (components) of your application are arranged in...you guessed it...in layers, with the unique characteristic that a layer can only make direct calls to the layer below it.

That is, a layer is tightly coupled to the layer next to it. 

Like this:

source: https://dotnetpeoples.wordpress.com/2011/05/16/three-tier-architecture-in-asp-net/

Or this:

depending on how mad you want to go with the layered architecture.

Component based architecture on the order hand, favours building applications by having semi autonomous components loosely coupled and able to collaborate and communicate with other components using messaging mechanism.

a CQRS application usually comprises the following components: the UI, Command Bus, Command Handlers, Repositories, Domain Objects, Event bus, Event Handlers, and all being glued together by commands and events. 

These components can be depicted below:

The components colored in blue are your application components. The ones in green are the components provided by the Axon Framework (although it is worth noting that Axon easily allows you to provide your own implementation of those components...for example you can easily swap out the implementation of the command bus to a custom implementation).

As you can see from the diagram, the components at the top are the components that changes the state of your application. It is also the area where your business logic would be implemented, while the components at the bottom reads or queries the state of the application: and in this clear separation, we have CQRS.

The flow in the application be summarized to be: 

Users using the UI components initiate intent to change state (book a ticket, edit a document, update a medical record etc). This intent to change state are modeled as Commands. The commands are passed on to the Command bus which finds the necessary Command handler that can handle the command initiated by the user.

The change of state is handled within the Command handler which uses the Repository to load the Domain objects and execute the business logic, applying the changes to their state.

Once there is a change in state,Events representing what changed are published to the Event bus. The event bus makes sure the necessary Event handlers are notified. Event handlers then updates the representation of the state of the application, which the UI can then query. In some instances, when required, you can have commands also initiated in response to an event.

Where Event Sourcing comes in.

The idea behind event sourcing is, instead of storing the current state of the application, we store the events that mutates the application.

Event sourcing can easily be used in a CQRS system, but it does not mean a CQRS system must use event sourcing. You can have a perfect CQRS architecture without event sourcing.

The Axon Framework provides the facility to easily use event sourcing.

What Next?

Now that we have had an overview of CQRS, seen the various components that would come to play, the next question is, how can Axon Framework be put to use?

The coming posts in these series would show exactly this. We will explore how to build the various components of a CQRS application using the facilities provided by the Axon Framework. 

To help illustrate the topics that would be touched on in this series, I have created a project on Github https://github.com/dadepo/exploringCQRSwithAxon. Which is a trivial application that models two bank accounts with the ability to debit and credit the accounts.

Each post in the series would start with instruction regarding the commit hash that needs to be checked out in other to have the project in the state for that post.

We start by exploring the Commands, Command Bus and Command Handling Component.