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.
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?
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
I think the following breaking changes would definitely be welcome:
- base-lining to JDK 17 (following Spring’s footsteps).
- apologies to the JDK 8 laggards.
- moving from Java EE to Jakarta APIs.
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.
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)