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.
For example, stateful command handlers would be a way to deal differently with your Command Model than the current aggregate approach.
Note that this is different from regular "Message Handling Components," as instead of having the handlers invoke the services to load a model, the model would automatically be injected in the handler.
Hence, a stateful command handler mitigates the situation where the aggregate Repository should be wired and invoked.
Furthermore, a stateful event handler would mitigate the injection of the model storage as well.
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 aggregates, this is straightforward, given the model identifier is typically identified in the message (so, the @TargetAggregateIdentifier).
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.
Notes
Note that issue #2399 might be a solution towards having stateful message handlers.
So, be sure to check that ticket when working on this issue.
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.
For example, stateful command handlers would be a way to deal differently with your Command Model than the current aggregate approach. Note that this is different from regular "Message Handling Components," as instead of having the handlers invoke the services to load a model, the model would automatically be injected in the handler.
Hence, a stateful command handler mitigates the situation where the aggregate
Repositoryshould be wired and invoked. Furthermore, a stateful event handler would mitigate the injection of the model storage as well.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 aggregates, this is straightforward, given the model identifier is typically identified in the message (so, the
@TargetAggregateIdentifier).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.
Notes
Note that issue #2399 might be a solution towards having stateful message handlers. So, be sure to check that ticket when working on this issue.