5 key benefits of migrating to Axon 4

In Axon's 10 year history (you’ve read that right, it turned 10 in January 2020!) we have striven to take all received feedback to keep improving the look and feel. Not only usability for developers has been a main spear point, but the performance and flexibility of Axon was greatly influenced by what you and other users told us.

In October 2018 the AxonIQ team released “Axon 4” combining Axon Framework with Axon Server, to further enhance developers to build applications based on these concepts. The main drive to release Axon 4? To improve the developer’s ability to focus on the business functionality of their application, whilst providing even more handles to address non-functional requirements their application requires. As shared earlier a great deal of these enhancements would not have been possible without the community’s insights. All combined we feel that Axon 4 provides the most straightforward solution to building business agile applications. Mind you, not just for seasoned Axon developers, but also for those just starting on this journey.

Although Axon 4 is over a year old, we still notice a great many usages of our previous major release. There is inherently nothing wrong with that of course, Axon 3 is a fine framework on its own. Regardless, any users of Axon 3 will be missing out on all the new features and enhancements all contributors have worked so hard on.

So, why not migrate from Axon 3 to Axon 4? We know that upgrading is typically a lot easier said than done. Especially from the product creators of course. Hence there should be clear advantages for you and your team to endeavor on an Axon 3 to 4 migration. Let alone to find the leverage to convince your business funding the work! It is this exact leverage which I would like to share with you. It is a summary of the most important improvements and new features you would benefit from if you migrate from Axon 3 to Axon 4.

So, what does Axon give you actually? It provides the necessary building blocks to employee DDD, CQRS and Event Sourcing within your domain, both as a monolith and as several (micro) services. Things like aggregate modeling, event stores, and message distribution are all tried and tested components given to you, with enhancement and additional features being introduced frequently. All this allows you to build on Axon’s 10 years worth of experience building applications like these, leaving you with implementing the business functionality. 

This article does not aim to explain the benefits of DDD, CQRS or Event Sourcing; there are already plenty posts around there explaining this in great detail. What it will convey are the five most beneficial improvements which have been introduced to Axon 4 so far.

1 - Unified Distributed Messaging Solution

Arguably one of the main reasons AxonIQ started in the first place. Sending commands, events and queries in a single application is straightforward with the provided message buses. Expanding this to communicate all messages between different instances required some expertise back with Axon 3. High availability or a desired microservices architecture however demanded this from Axon.

With Axon 4, distributing command, event and query messages has never been as easy. The seamless integration Axon Server provides with an Axon application makes sure of this. The predefined defaults of framework and server allow for enhanced focus on what matters to your application: the business functionality. Just so that you do not have to think about how to store events or how to distribute your commands.

With the unified messaging solution a developer can go back to implementing that new feature the business wanted or that bug withholding sales, instead of figuring out how to connect your applications with one another. Of course, you still have the freedom to choose a multitude of other open source solutions to this end, but none of these can be regarded as an out-of-the-box solution like Axon Server.

2 - Event Processing Enhancements

Updating your views, management information and search capabilities based on the latest events flowing through your system becomes a fact of life when using Axon. Ensuring this happens efficiently enough, especially with the potential for large bursts of events, is of utmost importance to stay ahead of the competition. To gain the upper hand, this process should be separated from the rest of your application, added with the option to scale out. Needless to say Axon keeps improving on this topic to minimize “read-model latency”.

It is the Tracking Event Processor in Axon, the technical component used to retrieve and handle events, which provides such flexibility. It can handle events independently from other parts of your system. Added, it allows for scaling out this capability by introducing more threads into the process of reading and handling messages. Axon 3 already contained the tracking event processor, but in Axon 4 it is the (sensible) default. This ensures that you will benefit from these perks immediately.

There was one major pain point with tracking processors in Axon 3 though. Several users noted they had peak performance requirements of their tracking processors. They could not always anticipate when these critical moments occurred though. Hence we had the request whether it was possible to dynamically scale a tracking processor.

In Axon 3 this was however not an option. Instead it required an operator to shut down the application entirely, remove the processor's old token (note: the token is used to maintain the processor's progress), change the configuration for scaling purposes, and only then could they start the application again. Obviously a rather intricate process, far from allowing dynamic scaling.

Hence in Axon 4 we introduced a solution to this, which we have called the “split and merge” functionality. Through the feature you can split the process into several processes or merge them back together. This thus makes dynamic scaling a piece of cake!

There was still room for improvement when it came to tracking processors though. Operators of Axon applications needed information and tooling to correctly control these processors. A dashboard allowed for monitoring the state of the processor, so that for example an operator could deduce whether he/she should scale up (or down). The tooling in turn was required to actually control the processor in a running system. Many of our developers heard these requirements and several client-specific versions have been built.

Due to this recurring requirement AxonIQ has started to provide tracking processor monitoring and tooling out of the box. Axon Server will create a dedicated page per tracking processor present in your application, showing all the known metrics and the required handles to take control over the processor. This provides a one-stop-shop for operators to check whether splitting or merging is actually needed. It will even open up the possibility for Axon Server to automatically scale up and down, which we will surely add in a future release.

3 - Real-time Event Streaming

Although the Tracking Event Processor is pretty neat, there was still one performance impact which could be tackled. In Axon 3, you were confined to using a relational database as the event store. The implementation made it so that a tracking processor had to poll the store on its own accord. This leads to a situation where tracking processors that reached the end of the event store are constantly checking the database for new events. A back-off period is in place of course. But still, this was and is a performance impact noted by a multitude of users.

We felt this could and should be improved on, thus we did so with Axon 4. We do this through real-time event streaming, made possible by Axon Server. In an Axon plus Axon Server environment, your tracking processor will register itself. In turn Axon Server will push any event it receives to the processors immediately, in real-time. This approach greatly enhances the performance of event handling as opposed to the polling approach used with relational databases.

4 - Aggregate Modeling Improvements

We all know that Axon provides a great stepping stone to DDD. Hence, domain modeling will be applied throughout the business by analysts and developers alike. It is in these modeling sessions that a hierarchy might occur. Let me give an example of this which we noticed at a bank.

This specific banking environment had modeled the notions of contracts in their application. A contract could however be of several types. Some actions could be taken generically, thus on any type of contract, but some were specific for a given contract type. When doing DDD this scenario is perfectly feasible. However, Axon did not support the same modeling experience in code, up till now.

In the latest release of Axon (4.3), we have introduced the notion of “Polymorphic Aggregates”, opening up the possibility to derive a model hierarchy. This will allow the previously mentioned banking environment to take their hands-on contract modeling session and map it directly into the application. This addition greatly strengthens the modeling experience, making the application resemble the domain more closely.

Another request we received several times was how to define an operation that would either create the model or update the model. This functionality is achievable with Axon 3, but essentially requires you to always try to create and thoughtfully catch the possibility of an exception that it was already created. If so, that’s when you would update the model. Doable of course, but “ugly” to write and a misnomer for the development experience with Axon.

You might expect this, but with Axon 4 you can thus define an operation to either “create or update” a given model. The developer will configure this on the model (read: aggregate implementation), omitting the need for him/her to draft up this functionality themselves.

5 - Multi-Context Support

When doing DDD, the notion of Bounded Contexts will definitely cross your path. Axon has been talking about the concept since prior to Axon 3, but true support for this was always in the hands of the developer themselves. Let’s give an example to clarify why defining and bounding different contexts is desirable in your application landscape.

We go back to the bank client mentioned in the previous section. They are using Axon in several departments of their company. For example the mortgage, credit card, and loan departments. Every department is in charge of their own piece of software, but these pieces will require communication with one another at one stage. For reporting maybe, or to validate a user’s credibility when applying for a mortgage.

The notion of a “user” will thus coincide with these departments. However, a “user” has a different set of requirements in the mortgage space than it has when applying for a credit card. To ensure consistency within the department, the mortgage application should not be polluted by the credit card’s idea of a user and vice versa. Instead, the required communication between the two should be confined to a consolidated global description instead.

It is the above scenario that describes the desire to derive distinct compartments which have their own context. Added, they should be shielded from outside notions of the world, bounding themselves from the rest. As I stated earlier, we at AxonIQ have been preaching this necessity, but did not provide an out of the box solution. A solution which bounds the communication between applications tied to the same piece of infrastructure for messaging and storage.

With Axon 4 however, we are allowing the option to define and support multiple contexts. This will ensure the communication of your applications will receive dedicated channels per context, as well as a dedicated storage location for the events. It greatly simplifies the work developers and operators would otherwise have put into setting up all these dedicated messaging channels and databases.

Conclusion

Concluding, we firmly believe that everything we are adding into Axon right now, the top five pointers among them, greatly increases any user's experience. If the above has convinced you to give Axon a try, know that we are more than happy to provide helping hands. Thus, please do not hesitate to contact us at AxonIQ!

For more technical information check the reference guide.

Go ahead and download Axon at https://axoniq.io/download