Axon Framework 5 suggestions

Hi all,

We as framework team have started to plan features for Axon Framework 5. Since this would be a breaking release, almost anything is possible. We would love to hear from you what you think can be improved, or new features worth considering to be part of a new major release.


Hi folks,

Great news! The first thing that comes in mind is an API redesign of the Query API.

Currently, the query API is very difficult to “communicate”. As a client you need to know the query type, the response type and the multiplicity (response type). In the same time, there is no easy type safe way (like a Java interface) to enforce or check this, since this must be communicated over the system boundary.

I don’t have a nice solution for this, but I feel that this is a problem in every project where Axon Framework is used.

The second thing is the way how the artifacts are cut in the framework. Jan Galinski and I spoke about this with Steven and even in the Podcast. The artifacts should be usage-oriented (query client, command client, command model, query model) and not feature-oriented (es, messaging, etc).

What do you think?




Hi there,

i’ve looked through already open issues and found these, that I find interesting:

At the end I just want to throw in another thought: I’m not a big fan of breaking changes. For me (as a developer) this had always been the absolute last resort. Of course, if there are valuable future features that will be made possible with a thought-through breaking change and there is a migration guide, then it makes sense. I hope, that there won’t be breaking changes only because semantic versioning is seen that way :slight_smile:

Kind regards

I think the following breaking changes would definitely be welcome:

And there some other nice to haves which would break the default behaviour:


Would love to see a command response include metadata about the event(s) that were created as a result of that command, so any following queries can include those details so the query handler implementation can block until those events have been handled in the projection


A way to customize the event retry scheme - it would be cool if the ErrorHandler could tell how many times a failed event is retried.

Please implement a way to prioritize event handling processors! If priority for processor A is higher than processor B, first handle events for A.

1 Like

This could be done now instead of waiting for Axon5, and wouldn’t be a breaking change.

@Aggregate annotation enhancement to allow a method name to be specified to use for the aggregateId as opposed to annotating a field or method. This is really a convenience thing more than a problem that needs to be solved.

Add a distributed query bus for non-axonserver modes (issue #613)