Exploring CQRS with Axon Framework: Closing thoughts

...and this post, is the final one, in the series of posts on Exploring CQRS with Axon Framework. It is a summary of my thoughts on CQRS as a pattern and the Axon framework as a tool used in achieving this pattern. If per chance you have not read the other posts in the series, I will recommend starting from the very first post: Exploring CQRS Architecture with Axon Framework: Introduction

That said, I proceed into the details of this post.

On CQRS

A tale of abstraction

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." Ew Dijkstra

Abstractions affect how we mould and interact with reality. They also restrict or liberate the tools and approaches we come up with, when finding solutions to problems we encounter.

Take capturing the quantity of things for instance. One approach is to use the now less popular Roman numerals. Another approach will be to use the more common Arabic numerals. Each method approaches and abstracts the task differently.

With roman numerals, quantity are moulded around seven characters: I,V,X,L,C,D,M. In arabic numerals, quantity are moulded around ten characters: 0-9 (when in decimals)

To be able to capture all numbers up to ten, in the roman numerals, you would only need 3 characters: (I,V and X) and rules on how to combine them. To be able to do the same with arabic numerals, a whooping 10 characters are needed (0-9): which might make the arabic numerals appear to be a less cognitively efficient abstraction…

But now, contemplate the steps that would be required to perform division in roman numerals to the steps required in arabic numerals? I would posit the arabic numerals abstractions provide a more elegant approach...

And that is the thing about abstractions: they influence not only the definitions we make of things, they inadvertently affect how we interact with things; what can be done, how it can be done and how easy it would be.

The numeral analogy also shows how an abstraction could be perfect in a particular scenario (counting ten things) but breaks down and becomes more of an hassle in another scenario (dividing). This holds true also with abstractions created in software...

The CQRS pattern posits that we abstract our software in a way that is radically different than what is obtained in the more traditional layered architecture. And thus, it presents it’s own definitions of reality. In doing so, it influences what we can easily do (or not do).

Why do we then keep having the "CQRS is too complicated" debate?

Well, thing is, most applications are information retrieval systems (or what is mostly referred to as CRUD) in which the end goal is clearly the retrieving and presentation of data from a database and saving of modified data back into the database. In such scenario, a layered (N-tier) architecture would be the most intuitive abstraction to use, as it places the database at a prominent and obvious position, with only layers, which influences how things get fetched and saved, put on top of it.

CQRS departs from this kind of abstraction. And if this is not appreciated, with the understanding that a different kind of abstraction usually open up alternative opportunities, then the indirections that come with CQRS might readily be concluded as unnecessary complexity.

The abstraction proposed by CQRS centers around having our software system as components that are clearly separated based on whether they write or read data. This opens up the ability to get things done that might not be that straightforward in the layered architecture approach.

For one, we can easily optimize the different components based on whether they read or write data. We can also easily employ component based and message driven approaches. Things like auditing, also, almost come for free with CQRS, when combined with Event sourcing.

Try building auditing features into a system that is modelled in the traditional layered architecture? I would posit CQRS/ES provides a far more elegant solution.

But CQRS is not the holy grail. Nothing is.

Just as with any abstraction, it does not come for free. It has its own indirections. A brilliantly formulated abstraction pays for it’s cost of indirection by the new semantic insight it reveals and the operations it easily permits. The task then is to be able to access the cost benefit for your unique use case and decide if the benefit pays for the cost. As Greg Young said about CQRS: CQRS is not a silver bullet...CQRS is not Event Sourcing...CQRS is not a good wife...but...CQRS can open many doors.

On The Axon Framework

Does CQRS even need a framework? The concept is pretty straightforward. Put your system together in a way that the components and domain that write data are different from the ones that read data.

That should be doable without the overhead of a framework.

Right?

Warning, anecdotal content ahead: I know of two projects that started off with the goal of employing the CQRS pattern without using any framework. One abandoned the approach and switched to Axon Framework due to the huge amount of effort that was spent writing boilerplate code. The second, slugged on, but ended up with some sort of Frankenstein’s creation: half what seems to be CQRS, half what seems not to be CQRS.

The Axon Framework itself came to be as a “revolt” against boilerplate code when building applications following the CQRS pattern. In the Interview InfoQ had with Allard (the creator of Axon Framework) he mentioned:

"I just heard about CQRS and I thought it would solve some of the problems that I was always encountering in a lot of my projects and it was just a playground for me to find out how CQRS would help. When I started doing that I noticed that much of the code that I had written had nothing to do with the, let’s say, business concept I was doing the proof concept for. It was just plumbing and everything so I thought if everybody has to do that, that is a waste of time. Then I started migrating some stuff to a public repository where people could download it and before I knew it there were other people using that and I thought that was interesting. So that is when I decided to make it a framework and go on."

So it is very possible to build systems following the CQRS pattern without employing any framework, just that, it might be easier and faster if a tool that abstracts some of the plumbing is put to use.

In the JVM Universe, the Axon Framework is probably the only tool strictly dedicated to supporting building application following the CQRS pattern. Other libraries and frameworks: from the Spring Framework to Akka can easily be adopted to construct software following the CQRS pattern, but their singular purpose is not to support CQRS. They are general purpose tools. In this respect the Axon Framework is different.

Axon having CQRS as its singular purpose allows it to then provide everything you would need to build a CQRS application, and even more. It not only provides the basic building blocks for CQRS: command handling, event dispatching etc, but it also provide supporting features like: command retry mechanisms, easy domain validation, test fixtures designed around commands and domain events, auditing both for commands and events, events sourcing, event replying etc.

After interacting with Axon framework for a while now, I can also say that it is easily customizable/extended. It is built in such a way that its components can easily be swapped out for custom ones. Even some the components that could be regarded as being core to the framework.

One thing though, the requirement to extend Axon's classes in other to get some things done in some instances, come across as a little stiff. A typical example is when creating Aggregates.

I guess I have grown to prefer the approach popularized by the Spring framework: in which functionalities are mostly powered by use of annotations and proxying. But...from what I am hearing, the upcoming Axon 3 would improve on this and aggregate roots would no longer need to extend Axon classes. Looking forward to that!

On Personal Journey With CQRS and The Axon Framework

CQRS felt really opaque at first encounter. The Axon Framework did not fare any better either.

For some (perhaps not surprising) reasons, the acronym: CQRS came across as an arcane and "enterprisey" concept which holds little value in everyday application development.

It had to take the exposure of working on a project built with the Axon Framework, an attempt to read Eric Evans book on Domain Driven Design, giving up on it, then reading Domain Driven Design Quickly instead, and then attending the two day-Axon Immersion Training before the pieces started to fall into place.

In retrospect, I can see that the initial complexity was not due to the fact that CQRS itself is intrinsically complex. The complexity was largely due to it not being familiar: plus the fact that it also encompass (or touches on) a varied amount of concepts: from DDD to Event Sourcing.

The dearth of gentle introductory materials on CQRS and especially on Axon Framework did not also help matters. For instance, what is supposed to be a Quick-start guide on Axon Framework, went ahead and threw in Event Sourcing into the mix in one go. It is indeed a quick start guide, because I remembered going through the steps iterated in record time, getting the application working, but ended up not really understanding how everything fit together.

The motivation for writing the Exploring CQRS with Axon series was basically to write what I wished someone else had written when I started exploring CQRS and the Axon Framework.

I do hope the series ends up being useful to others :)

Additional Resources

To conclude, I list some of the resources that have helped me in developing a better understanding of CQRS, and thus, how to use the Axon Framework in achieving it.

Books
Domain Driven Design Quickly by InfoQ

Tutorials/Posts
Introducing the Command Query Responsibility Segregation Pattern
CQRS by Martin Fowler
http://cqrs.nu/Faq
Axon-Trader Sample Application documentation

Videos
CQRS for Great Good by Oliver Wolf
Building flexible and high performance software with CQRS and Axon Framework by Allard Buijze
CQRS and Event Sourcing by Greg Young

...and the Axon Framework User Google group will also help. There, you are likely to find past conversations enlightening. It is also a place where you can ask questions about Axon Framework; from how to achieve certain tasks to tips on design considerations when working with the framework.