@EventHandler vs. @EventHandler


I just wanted to give some feedback after training a few new developers as my team transitions from our Axon-based proof-of-concept to real development.

One point of confusion is the difference between @EventHandlers as they occur inside and outside of (event sourced) aggregates.

As you know, inside they are generally private methods, used solely to update internal state (no external queries allowed), and most importantly must not trigger additional business logic. Also they are not registered with the event bus (tough to explain after I just got through describing how the event bus works), and are invoked before the unit of work “commits”.

Outside (in Spring components), @EventHandlers may update query models, dispatch other commands, send messages, etc. A single component (class) may subscribe to events from multiple aggregates. They are almost completely opposite in many ways.

So my feedback is, for Axon 3.0, would you consider renaming the annotations to give separate names for separate concepts. There is already @SagaEventHandler, which makes it very clear that it is a different animal (yet closer to external @EventHandlers than to those inside aggregates). Perhaps one of @AggregateEventHandler, @StateUpdater, @Apply, or something like that. (The Axon framework is so impressively clean and clear; this is the one wart that unfortunately comes up very early in training.)

Another possibility would be to allow customizing the annotations scanned (which would also satisfy those who wish to remove Axon dependencies from the application’s core domain).


Hi Peter,

I have to admit that you’re not the first one to suggest this. Your suggestion to allow custom annotations is a good one too. Recently, some contributions related to routing keys from Mark Ingram were moving into this direction as well. I like the idea.

The good news is that this concept doesn’t have to wait until 3.0 (for which I have no concrete plans yet). This can easily be done in a backwards compatible manner, by accepting both @EventHandler and the new annotation (whatever the name will be).

Thanks for the feedback. I will create an issue right away to make sure it gets done.