Although the Saga support of Axon Framework has proven to be a powerful and desired tool, we feel it's paramount that we examine the current implementation.
The most obvious change to revisit is the naming.
When the saga was constructed back in version 0.7.0 of Axon Framework, the term saga was still very much in flux.
With the current knowledge of this space, we would much rather rename all usages of "Saga" to "Process" / "Process Manager."
Furthermore, once the Axon Framework supports the dynamic consistency boundary (DCB for short), we would likely be able to eliminate a large portion of the saga storage.
As, instead, we would open a stream consisting of all associated models, recreate the saga, and then invoke the handler.
You would, in essence, have an event-sourced saga when taking this route.
So, next to the fact it would drop the need for an old-fashioned persistent Saga Store (although, we could leave this as a user choice, of course), it would ensure the process is:
More easily adjusted state-wise, since it is event sourced and a new event sourcing handler is easily added.
Ensuring the process state is up to date on each load from the store.
Lastly, we can also investigate how the idea of stateful message handlers may replace the old approach entirely.
The naming pointer should definitely be covered when transitioning from Axon Framework 4 to 5.
The other ideas are, at this stage, still under discussion.
Hence, a "must" label is warranted, but the "under discussion" label is too.
Although the Saga support of Axon Framework has proven to be a powerful and desired tool, we feel it's paramount that we examine the current implementation.
The most obvious change to revisit is the naming. When the saga was constructed back in version 0.7.0 of Axon Framework, the term saga was still very much in flux. With the current knowledge of this space, we would much rather rename all usages of "Saga" to "Process" / "Process Manager."
Furthermore, once the Axon Framework supports the dynamic consistency boundary (DCB for short), we would likely be able to eliminate a large portion of the saga storage. As, instead, we would open a stream consisting of all associated models, recreate the saga, and then invoke the handler. You would, in essence, have an event-sourced saga when taking this route.
So, next to the fact it would drop the need for an old-fashioned persistent Saga Store (although, we could leave this as a user choice, of course), it would ensure the process is:
Lastly, we can also investigate how the idea of stateful message handlers may replace the old approach entirely.
The naming pointer should definitely be covered when transitioning from Axon Framework 4 to 5. The other ideas are, at this stage, still under discussion. Hence, a "must" label is warranted, but the "under discussion" label is too.