Axon Framework: CQRS, Event Sourcing and Messaging on the JVM

The problem Axon Framework solves for JVM teams

Most Java services start as a controller calling a service class that writes rows to a database. That is fine until the same business fact has to be known in three places: the write path, a read model shaped for a screen, and an integration that must react to the change. At that point teams hand-roll an outbox table, a poller, a retry loop and a set of DTOs, and the hand-rolled version is where the bugs live.

Axon Framework addresses that by making messaging the primary structure of the application. The README describes it as a framework for "building evolutionary, event-driven microservice systems based on the principles of Domain-Driven Design (DDD), Command-Query Responsibility Separation (CQRS), and Event Sourcing." It supplies the building blocks those principles need: aggregate design handles, aggregate repositories, command buses, saga design handles, event stores and query buses, with defaults for each.

The intended audience is a Java or Kotlin team that has already decided the domain model matters more than the persistence schema. If your team has not made that decision, the framework will feel like ceremony. The README is explicit that the messaging core is what enables the evolutionary approach, through location transparency: the same command handler can be invoked in-process or across a network without the caller changing.

How the buses, aggregates and event store fit together

The architecture is a set of buses with handlers attached. A command bus routes a command object to exactly one handler. That handler typically loads an aggregate from an aggregate repository, calls a method on it, and the aggregate publishes events. An event bus fans those events out to any number of subscribers, which is how read models get built and how other components react. A query bus routes a query object to a handler that returns a result, which is the read side of CQRS.

Event sourcing sits underneath the write side. Instead of storing the current state of an aggregate, the repository replays its events from an event store to reconstruct it. The README lists the event store as one of the provided building blocks. Sagas handle the long-running case: a saga reacts to events and can send further commands, which is how a process that spans several aggregates or services is expressed without a central orchestrator holding state in memory.

The distribution story is where Axon Server enters. The README states that the quickest road to a distributed deployment is Axon Server, which provides a distributed command bus, event bus and query bus, plus an event store implementation for scalable event sourcing. Axon Framework on its own gives you the programming model and in-process defaults; Axon Server is a separate product from the same vendor. That split matters when you cost the stack.

Installing Axon Framework and running the quickstart

The README does not print a Maven snippet, so the honest starting point is the download it names. The quickstart page of the documentation is described there as a simplified entry point into the framework, and the quickstart project itself is a zip hosted on the vendor's download host. Fetch it with curl or wget, then unzip it and build with the Maven wrapper the project ships.

curl -O https://download.axoniq.io/quickstart/AxonQuickStart.zip
unzip AxonQuickStart.zip
cd AxonQuickStart
./mvnw spring-boot:run

That gives you a running application with the command bus, event bus and query bus already wired, which is the point of the quickstart: you see the messaging model working before you configure anything yourself. If you would rather read the wiring than run it, the hotel demo and the code samples repository are the fuller examples the README points at, and this repository's examples directory carries runnable projects such as university-java-springboot-4 and university-demo-kotlin.

For your own project, the dependency anchor is the Axon Framework BOM on Maven Central, published under the org.axonframework group. Importing a BOM in dependencyManagement pins the versions of the modules you then declare, without repeating a version on each one. The repository layout shows which modules exist to declare, grouped as messaging, modelling, eventsourcing, conversion, common and legacy, with axon-5 and migration directories alongside them.

Where Axon Framework becomes the wrong choice

Event sourcing is the constraint that decides most adoptions. If your aggregate has to be reconstructed by replaying every event, the event stream becomes a permanent public contract. Renaming a field, splitting an event, or changing the meaning of a value requires an upcaster or a migration, and the migration directory in this repository exists precisely because that work is real. A team that changes its domain model weekly will feel that cost more than a team with a stable domain.

The second constraint is operational. The README frames Axon Server as the path to distribution, and Axon Server is a separate product with its own deployment and licensing. Running the framework without it means running the in-process buses, which is a legitimate choice for a modular monolith but does not give you the distributed buses. The README does not document a rollback story for a partially migrated event store, and it does not describe what happens to in-flight sagas during a deployment. Those are questions to raise with the vendor before you depend on them.

Finally, the framework assumes consistency requirements that a simple service does not have. A CRUD application with one database, one writer and no need for an audit trail gains nothing from a command bus. The buses are indirection, and indirection that no requirement justifies is just a place for bugs to hide.

Axon Framework compared with Spring Modulith and plain Spring events

The nearest alternative for a Java team is Spring's own event publishing plus a modular structure, often Spring Modulith. The difference is where the event lives. Spring's ApplicationEventPublisher is in-process by default: publish an event, listeners run, and if the process dies the event is gone unless you add your own outbox. Axon Framework treats the event as a persisted fact in an event store, and the aggregate is rebuilt from those facts. That is a different durability guarantee, and it is the reason to pick one over the other.

A second alternative is building the same thing by hand: an events table, a Kafka or RabbitMQ topic, and a projector. That gives you full control and no framework vocabulary to learn. What you lose is the aggregate repository, the saga abstraction, the query bus and the consistent programming model across all three. The README's claim is that this lets you "shift focus from non-functional requirements to your business functionality." Whether that trade is worth it depends on how much of the messaging plumbing you would otherwise write yourself, and how many teams will write it differently.

Axon Framework also carries a migration module and a legacy module, which signals that the project has been through at least one major model change. Version 5 is the current line, with 5.3.2 released on 2026-09-10 according to the release list. Teams on earlier versions should read the migration material before upgrading rather than assuming source compatibility.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent: 5.3.0 on 2026-08-05, 5.3.1 on 2026-08-14 and 5.3.2 on 2026-09-10. That cadence means patch upgrades arrive often, and a team that pins a version will accumulate distance from the current line quickly. The BOM exists to make the version decision a single edit, which is the practical way to manage this.

The licence is Apache-2.0, stated in the repository and carried in LICENSE.txt. That permits commercial use and modification, and it does not require you to publish your own source. It does not, however, cover Axon Server, which is a separate product with its own terms. The README treats Axon Server as the recommended path to distribution, so a licensing review that stops at the framework repository will miss the component most likely to carry a commercial condition. Nothing here is legal advice, and the terms of Axon Server should be read directly.

Upgrade cost is concentrated in the event stream, not the API. Because events are persisted facts, a framework upgrade that changes how events are serialised or how aggregates are loaded touches data that already exists. The repository's migration and legacy modules exist for that reason. A team with a large event store should budget for a replay in a staging environment before touching production.

Editorial conclusion

Adopt Axon Framework when your domain genuinely needs an event log and a command/query split, and you are willing to organise code around aggregates, commands and events. Do not adopt it for a CRUD service with a single relational database, because the buses, the event store and the saga machinery all cost something you will not get back. Before committing, verify the version alignment between the Axon Framework BOM and any Axon Server or extension you plan to run, and check the migration module against your current release.

Frequently asked questions

Official sources

1. AxonIQ/AxonFramework on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases