Axon and reactive systems

There is no need to introduce Axon Framework (and furthermore Axon Server) to the Java developers passionate about DDD, CQRS and/or Event Sourcing. In that space, there are not many tools out there that are both battle tested and pleasant to work with. We at AxonIQ are super happy to be able to empower the ever growing community of practitioners relying on the above mentioned concepts and standards. 

However, being good at something has its drawback. The most harmful of them is probably pigeonholing. It’s easy (and likely wrong) to think of Axon as nothing more than a particular implementation of an opinionated combination of DDD, CQRS and ES. Trust me I know what I am talking about. There was a time when that was my view too. If you are mentaly there today, please allow me to try to put the things in a wider perspective in the next few paragraphs.

Microservices

Let's start by talking about distributed systems of systems (a.k.a. Microservices). It is already a widespread and deeply sought after pattern by both individuals and companies. Sadly, the amount of articles describing failures with this approach is comparable to the amount of those glorifying it. The process of decomposing a complex domain (monolith) into meaningful self-contained subdomains (microservices) and providing proper communication channels between them is far from simple. 

Of course, Axon does not magically make microservices simple. What it helps with is applying patterns that favor autonomy. Well-defined domain models (DDD) draw boundaries. Communicating facts (ES) reduces coupling. Separating concerns (CQRS) makes scaling individual components safer. There is a whole article about Microservices that explains those in more detail. But in general the purpose of Axon is to not let you give up on the “why” due to the complexity of the “how”.

Growing in parallel with Microservices is the Reactive approach. From The Reactive Manifesto, through various specifications and protocols, to establishing a vendor-neutral Reactive Foundation around those - many smart people have put a great deal of effort in explaining and promoting the benefits of reactive systems and reactive programming in the past decade. 

The Reactive System Principles

The most recent addition to that effort is The Reactive Principles - a collection of  practical guidance and techniques for building individual services, applications, and whole systems. It was put together by experienced Reactive practitioners. It’s a piece worth reading by anyone interested in highly concurrent, distributed, performant, scalable, and resilient software. 

Of course, achieving  truly reactive systems is a challenge. There is no silver bullet or a magic framework that does it all for you. Many technologies have their significant roles in such systems and Axon is one such player. The following quote from “Assert Autonomy” principle

“Communicating fully self-contained facts  -  modeled closely after the underlying business domain  -  gives the recipient the power to make their own decisions without having to ask again for more information.”

makes it perfectly clear how the core principles and techniques of Axon bring you closer to truly Reactive systems. Furthermore the “Communicate Facts” reactive pattern essentially converts what Axon practitioners have been doing for years into a rule of thumb:

“... rely on immutable state - values representing facts - which can be shared safely as local or distributed events without worrying about corrupt or inconsistent data, or guarding it with transactions or locks”

There are more reactive principles and patterns where Axon can also play a role - directly or indirectly.

The bottom line

One can see Axon as a collection of tools helping Java developers do some DDD, CQRS and ES. In fact, that is not wrong. Much like it’s not wrong to think of a printer as a machine that puts some ink on paper sheets. But in both cases that’s not the point. The point is that you get something of value and meaning by comfortably interacting with a tool that encapsulates and hides from you the burden and the mess of the underlying process. 

Much like the purpose of your printer is to print your documents and photos, the purpose of Axon is to produce better software systems.