Several business rules tend not to be a part of the main flow of a certain compenent, but rather policies or rules enforced by components on side. This is already supported by Axon by command interceptors but to not have edit the spring config of the command bus for every such component added, we created an IntercepterRegistry which in itself is a CommandInterceptor that other interceptor may register with. Since an interceptor might want to intercept several types of commands we also added annotation support, much like the @EventHandler annotation for event handlers.
This makes it possible a component plugged in to the main spring context to get a hold of the InterceptorRegistry, register itself and then intercept the commands that are handled by its @CommandInterceptor annotated-methods. Wouldn’t it be even cooler if this support was build in to Axon? : ) So that you only had to worry about annotating your interceptors…
Any thought on this?
If you would be interested in incorporating it into Axon I would be glad to give it a shot.
sounds interesting. In the interface based implementation, one is required to call chain.proceed(). How do you do that using the @CommandInterceptor method? Do you require a parameter for the interceptor chain (making it more error prone if you forget it)?
Another issue we’d need to solve is ordering of the interceptors. Some need to be executed before others. For example, you want (structural) validation done before you start a transaction, to prevent wasting resources.
In our case all interceptors work fine with doing their thing before any other interceptors and therefore we let the wrapper (the one implementing CommandHandlerInterceptor) takes care of the proceed call. If you would like some other characteristics you could maybe add those as a property on the annotation restOfChainTraversal={pre, post, inbetween}, where only the inbetween config would require you to take the chain as a parameter to able to decide when it should be called. I can’t really see why you would want to run the other interceptors before this one, instead of just setting a lower priority on this.
The ordering I guess could also be solved by a priority property in the annotation as well as in the spring config somehow. Maybe wrapping each interceptor-bean in an axon:interceptor-type that has the priority as an optional second property.
Do you see any obvious flaws? Would something like that fit into the Axon idea?
the idea definitely fits. I was just wondering about the “restrictions” you were imposing on the interceptors. Having them run “before” with the possibility to prevent execution by throwing an exception is probably fine for 80% of use cases. In the other cases, one would just need to implement the interface.
The problem of ordering is something that can be fixed in a later stage. Again, if that’s important, one would just need to manually configure the interceptor before the “autowired” one.