While working on Axon Framework 5, we should take the opportunity to adjust the Event Processing logic.
First and foremost, the new Unit of Work, ProcessingContext, and MessageStream APIs (in #3069) are a must to be implemented by the existing event processing API.
Apart from this, this issue is about topics like:
Event Handling Component -> Processing Group -> Event Processor
Infrastructure layering
Configuration
Defaults
Event Handling Component -> Processing Group -> Event Processor
Do we still need the layering from Event Handling Component in Processing Group in Event Processor?
When you have been working with these layers, the benefits become clear.
However, it is, and will be, a hard topic to explain to users throughout.
It might happen that this is the right flow, but this is the right time to take a step back to reconsider.
Infrastructure layering
This reflects a simillar task as has been done with the command bus in PR #3003.
Thus, we break down the complex Event Processors and Processing Groups (internally called EventHandlingInvokers) into there different concerns.
This layering will enhance the modularity and, thus, the testability for us.
Furthermore, it could upon up an easy way for users to inject their own behavior at the exact level in the process.
Configuration
Rework the configuration API to align with the new infrastructure layering.
Through this, it should become easier to configure event processing to a user's liking.
Defaults
For the components that remain we should revise the defaults currently in place.
Think about things like:
From TrackingEventProcessor to the PooledStreamingEventProcessor
The use of the scheduled thread pool executor in favor of virtual threads
The exception-propagating ListenerInvocationErrorHandler instead of the logging version.
While working on Axon Framework 5, we should take the opportunity to adjust the Event Processing logic.
First and foremost, the new Unit of Work,
ProcessingContext, andMessageStreamAPIs (in #3069) are a must to be implemented by the existing event processing API.Apart from this, this issue is about topics like:
Event Handling Component -> Processing Group -> Event Processor
Do we still need the layering from Event Handling Component in Processing Group in Event Processor? When you have been working with these layers, the benefits become clear. However, it is, and will be, a hard topic to explain to users throughout.
It might happen that this is the right flow, but this is the right time to take a step back to reconsider.
Infrastructure layering
This reflects a simillar task as has been done with the command bus in PR #3003. Thus, we break down the complex Event Processors and Processing Groups (internally called
EventHandlingInvokers) into there different concerns. This layering will enhance the modularity and, thus, the testability for us. Furthermore, it could upon up an easy way for users to inject their own behavior at the exact level in the process.Configuration
Rework the configuration API to align with the new infrastructure layering. Through this, it should become easier to configure event processing to a user's liking.
Defaults
For the components that remain we should revise the defaults currently in place. Think about things like:
TrackingEventProcessorto thePooledStreamingEventProcessorListenerInvocationErrorHandlerinstead of the logging version.