Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Basic Concepts and the Future of Axon, a CQRS and Event Sourcing Framework

Basic Concepts and the Future of Axon, a CQRS and Event Sourcing Framework

This item in japanese

The adoption of Axon Framework is growing rapidly and recently hit one million downloads, Allard Buijze noted in his presentation at the recent Event-Driven Microservices Conference in Amsterdam, where he described the basic concepts, the history and future of Axon, a framework for systems based on DDD, event sourcing and CQRS.

Buijze started by noting that events are very special; they describe something that happened and are part of the history of a system. We can find problems from the past and we can set expectations on the future. For Buijze this is what drives the event sourcing practice – use your events, not just as a side effect, but as the source of truth in your applications.

Buijze also pointed that it’s important that a service is consuming its own events – this is essential in event sourcing. If your service is making decisions based on internal data, not on the events, you are not doing full event sourcing. You have an event driven architecture, but you cannot guarantee that the events are a true representation of what has happened in the service.

In Buijze’s experience there are a lot of microservices architectures based on entity services, and he calls this design technique noun-driven design. The idea is to find all the nouns in the documentation describing the new system, these will be the services, and all the verbs become the API calls. This technique will likely result in a distributed big ball of mud, with all services depending on each other. If one service goes down the whole system will be unusable.

Instead of starting with microservices Buijze wants us to start with a monolith. they are easier to deploy and refactor, although they are harder to scale, and he points out that we shouldn’t confuse a good monolith with a big ball of mud. The strategy he recommends is to start with the monolith but making sure there is a clearly defined structure inside. With time, when too many people have to work with the same parts of the code, then it’s time to extract some components, preferably without changing other parts. As time passes and needs arises, more and more components can be moved out.

To help in extracting components, location transparency is very important, and Buijze notes that the primary feature of Axon is not CQRS, it is location transparency between the components inside an application. If two components are not aware of their respective location, then you can change that location. It also means that you don’t have to know in which service a certain operation is – you just send a message and it will find its destination.

A component should neither be aware of nor make any assumptions about the location of components it interacts with

Events are important, but Buijze points out that there are three categories of messages that a component has reasons to send and emphasizes that an event is not the same thing as a message:

  • An Event is when something has happened. They are distributed to all handlers and no results are returned.
  • A Command is when you want the system to do something. They are routed to a single handler and return a result.
  • A Query is when you want to know something. They return a result.

To support the promises of location transparency and work with these different types of messages, AxonHub was released in 2017, at last year’s conference. Buijze describes it as a messaging platform that understands the different type of messages, not the content, and is capable of routing the different types to the correct destinations. He notes that the ideas of the hub are comparable to the microservices concept of smart endpoints and dumb pipes even though the pipe in this case is aware of the message types.

Looking into the future, Buijze believes that the microservices evolution will continue, and he also believes that the way the Axon components work and communicate can be useful in a serverless environment. Their first step in this direction will be to provide a SaaS solution, but he also noted that they have more to learn and that there is more work to be done to be able to use a serverless environment efficiently.

Earlier this year the Axon team released AxonDB, a purpose-built event store. The store is used by AxonHub for storing events and because of that they have decided to merge these two products into Axon Server which was announced during the conference. The server is available both as open source and as an enterprise version.

The work on the next version of Axon, version 4, is ongoing and the first milestone was recently released. Product launch is planned for October 18.

Axon Framework is an open source product for the JVM platform, founded in 2009 by Allard Buijze. In July 2017 a separate company, AxonIQ, was founded to solely work with the Axon products.

Rate this Article