Axon 3.0 milestone 4 Released

Hi all,

those who have attended the Webinar already know. If you haven’t, here is the news: milestone 4 of the Axon 3.0 release is available.

It solves a few minor issues that came up in milestone 3, such as the NullPointerException when Axon wasn’t able to resolve a parameter type on an annotated handler.
A few classes have been moved to packages where they make more sense. While they’re mostly internal classes, you might have to reimport certain classes.

Snapshotting has been re-introduced, using a new API. Configuration of snapshotting is similar to the old way, albeit simpler. Especially when used in combination with caching.

The biggest introduction is the Configuration API. It allows you to quickly set up the Axon Infrastructure and only configure the exceptions to the default. Configuring the infrastructure for an Event Sourced Aggregate (Repository, AggregateAnnotationCommandHandler, etc) is only a single statement: configureAggregate(MyAggregate.class). In Spring, it takes as much as a single annotation on your Aggregate Root.

The milestone 4 release has been published in Maven Central, so all you need to do is update your maven/gradle dependencies to 3.0-M4.
If you missed the webinar, it has been published on YouTube:

Have fun. As always, we welcome all feedback.
Meanwhile, we’ll be working on getting Axon 3 to the RC stage…



That was a useful peek at Axon 3.

Since it seems like this webinar is going to be the first of a series, I'd love it if a followup would include a "transfer money from one account to another" command, since that opens up several topics this initial session didn't touch on.

I see that command is implemented in the new AxonBank demo application so I expect you're already planning to cover it. It'd be great to hear some discussion about the design decisions, e.g., why a transfer is modeled as an Aggregate while a deposit or a withdrawal isn't.


Just in case you don’t get any answer here: there is a DDD/CQRS google groups for this, those ppl love to talk about the why and how of DD design decisions.


Hi Steve,

the new Axon 3 sample is still work in progress. Don’t use it as an example just yet.
And even then, in aggregate design, there are so many little things that impact the design decisions to make, that it’s hard to use an example as a reference for that.

When designing your models, take a look at the concept of Event Storming, by Alberto Brandolini. It’s a very effective (and fun) way to discover a model.



Hello Allard!

I enjoyed the presentation and afterwards tried to convert the Axon 2 QuickStart Guide to Axon 3.0 M4. I have a couple of questions:

  1. Has the FileSystemEventStore been scrapped?

  2. In the presentation you use Lombok to generate a default no-arg constructor… In the QuickStart guide I found the following section:

“When we run the tests again, we get another exception: IncompatibleAggregateException: The aggregate [ToDoItem] doesn’t provide a no-arg constructor. Easy, let’s create a no-arg constructor then. Axon uses the no-arg constructor by default to create uninitialized aggregate instances. Check out the reference guide for ways to change that.”

But I was unable to find anything conclusive in the reference guide or in this forum. Default constructors are not really a big deal for me. I’d just like to know whether there is a mechanism similar to the one used in Jackson available. (Jackson relies on Java 8 and the “parameters” compiler option. See for a well-written example.)

  1. I’m unsure what to do with AnnotationEventListenerAdapter.subscribe(new TodoEventHandler(), configuration.eventBus());.


  1. Yes, the FileSystemEventStore has been removed. It wasn’t really suitable for production environments. For quick setup, you are better off using an HsqlDB or the in-memory storage engine.

  2. The reference guide is still being modified for 3.0. By default, Axon uses a no-arg constructor. However, you can configure a custom AggregateFactory in each Repository implementation. The AggregateFactory allows you to define how a new aggregate instance is created when rehydrating one from events.
    A Jackson like solution isn’t available, because you aren’t reconstructing an aggregate from a single ‘state document’. Instead, there is an entire stream of events. Enforcing that on a constructor the aggregate would put all that complexity in the aggregate. A no-arg constructor is a lot simpler…

  3. With the @EnableAxonAutoConfiguration annotation, you just need to register the bean itself. There is no need to wrap it. In a non-spring environment, you can simply register the event handler bean in the configurer or pass it as a parameter to the EventProcessor instance (actually, it’s in the invoker). Neither way requires you to wrap it using the AnnotationEventListenerAdapter anymore.