Skip to main content

Basic concepts Axon 4.0

  • Axon 4 defines the start of pairing Axon Framework and Axon Server.
  • The enterprise products, previously known as AxonDB and AxonHub, are integrated in Axon Server as one whole (which will be Open Sourced).

Axon Server as Default

The most up front change is the pairing of Axon Framework with Axon Server as the default approach for delegating messages between and throughout your applications. Very important for this step is the fact that Axon Server has more free-to-use capabilities then it used to, enough so that moving into production with it is a logical first step to make.

Thus in Axon 4, the configuration will attempt to connect to the default location for Axon Server and notify you if it is inaccessible. If you want to proceed with the previous defaults, you can either remove the ‘Axon Server Connector’ dependency or configure all the required infrastructure components yourself.

Axon Extensions

We have also marked several of our framework integral solutions as extensions. This breaks down to our MongoDB, JGroups, AMQP, Kafka and Spring Cloud modules. All of these have been promoted to a dedicated repository, placed under ‘org.axonframework.extensions’. Doing so allows for different release and bug fix cycles per extension, and thus overall simplifying community contributions for each extension.

Framework Modularization

In line with the move of the extensions into dedicated repositories, we viewed that the old module structure of the framework was not up to par with where the framework is moving towards. The old package, `axon-core`, was becoming too big and has been split into ‘event sourcing’, ‘modelling’, ‘messaging’ and ‘configuration’.

This opens up the usability of for example just the ‘messaging’ concepts if your application (or microservice) only deals with Commands, Events and Queries. In that case it should not be bothered with how to model an Aggregate or how to Event Source your aggregate.

Or you might have a dedicated application for just your Aggregates, which you want to Event Source. Depending on the new ‘event sourcing’ module is all that it takes.

Other noteworthy new features

  • Our Infrastructure components no longer contain constructors, but take the Builder Pattern. This allows us to introduce new components to for example the Event Bus without immediately breaking backwards compatibility with previous versions.
  • We have introduced a dedicated ‘Command Result Message’. We saw it made sense to convey any potential results from the command handling, albeit typically an OK, an ID or an exception, was very beneficial to pack in the notion of a message. Note that if you are using the Command Gateway to publish commands, you will not notice this shift, as the Command Gateway abstracts the notion of the messages for the users.
  • In release 3.3, we took a stab at updating the configuration of your Event Handlers and Event Processors. Following to this operation, we noticed we did not take the right path in regards to this and hence we have adjusted it again. We have made the deviation between the Event Processing Configurer and the Event Processing Configuration. The configurer is used when the application is being configured, whilst the configuration is the end result of the configure steps. This is in line with how the overall infrastructure Configurer/Configuration already works for the framework.
  • We have removed any functionality which was marked deprecated.

A more exhaustive list of what has been done for Axon 4 (and for what is slated in the future), you can be found here.

Reference Guide HTML

Sign up for our newsletter

monthly updates about new product releases and invitations to AxonIQ events

We use cookies to analyze our traffic, to optimize the site functionality and to make sure you get the best experience on our website. We do not place cookies to invade your privacy. By continuing to use this site you are giving us your consent to our cookies. Read cookie notice here