Introduce Stateful Event Handler

[smcvb]

Feature Description

A generic form of stateful message handler is beneficial for any message handler in the system. Having this would help to construct models that contain no framework- or library-specific code.

This issue is all about stateful event handlers. A stateful event handlers would be a way to automatically inject the projection that should be updated. Hence, there is no need for the user to wire a repository and invoke methods on it; the stateful event handler could do that for the user. Note that this is different from regular "Event Handling Components," as instead of having the event handlers invoke the services to load a model, the model would automatically be injected in the handler.

This could also be used to have an alternative to the current Saga implementation. Instead of the saga class being the state, process, and handlers in one, we would have (a) separate event handler(s) receiving the transaction state and performing the process.

This idea obviously begs the question of how we will automatically load the state (aka, the model) for these handlers. For query models, a more dedicated model support would simplify this greatly. Or, a simple way to inject a "model loader" by the user.

Lastly, for the sagas, but also in part query models that consist of several identifiable sequences, the DCB (dynamic consistency boundary) functionality that AxonIQ is working on will be a great boon. Although solutions are imaginable without the option to combine several identifiable sequences (e.g., just reading from a point in time until the end), having dynamic consistency boundary support would make the stateful message handler idea truly fly.

Current Behaviour

You could regard the Aggregate and Saga support as a form of stateful message handler, although it is rather a "model message handler" approach.

Wanted Behaviour

An automated way to make concise message handling classes that receive a message and the model to act on.

When picking this up

Be sure to check issue #3095 about stateful command handlers and pull requests #3296 and #3314 when picking this up. Finding a means to inject any form of loader or persister into the StateManager will be large part of the investigation here. From there, it would be good to figure out if the loader solution is sufficient for event handlers updating a projection or reacting on a saga.