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.

5 Likes

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?

Cheers

Simon

2 Likes

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
Johannes

I think the following breaking changes would definitely be welcome:

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

2 Likes

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

2 Likes

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)