Currently in the framework there is this persistent state machine mechanism called Saga.
From what i’ve read across books and articles i came up to conclusion that it is not exactly a saga.
My understanding is that saga needs to be component which explicit behavior is to compensate failures, so saga uses a process manager to handle some workflow but also is defining the compensating actions.
They both handle persistance so it all comes down is the intent of a component.
I’m not sure why this component was called that explicitly, any points on that would be helpful.
(I understand that it is quite cherry picking of naming things, but it would be insightful for me if i understand the axon’s decisions more clearly)
This is exactly what I thought after reading „Exploring CQRS and Event Sourcing“ by Microsoft (2012).
In DDD, discussing names should never be seen as cherry picking.
Since axon already existed in 2012, only sagas might had been known back then.
Maybe it is seen as a building block, that might mostly be used for „process managers“,
but also is capable to be used to realize a saga, especially with the philosophy of „location transparency“.
But I’m only guessing.
Johnny’s comment is very accurate, actually. When Axon started in approx. 2010, only the term Saga was used to describe “long-running transactions”, where “long” means anything longer than a single, atomic, commit.
By the time the concepts of Process Manager and Saga were properly defined, and when those definitions started being more accepted, we decided not to change the name/mechanism anymore in Axon to avoid compatibility issues.
We’ll start a discussion to find ways to better align our naming to the industry standards.
After another set of articles and playing with my own model i think that the process manager should not be statefull, well it does not need to be.
Here’s why:
The way of describing process of some action can be described in simple terms of dispatching commands based on the events, just like in saga.
However when designing an aggregates its a good option to consider such aggregate as a process.
When we consider aggregate as a process then we can link it with some stateless process manager that would drive the aggregate ‘flow’ based on events emitted by this aggregate.
Since aggregate is a process means that any failure in the processing should be handled within an aggregate, meaning it should emit an event (rare cases by throwning an exception, but they also can be handled in process manager without any external state)
When comes to saga, their responsibility is basically link two bounded contexts together, disconnected things do not have everything needed to drive some bigger process in their events (duh) so a way to follow the state and make appropriate associations is required.
So basically i take back my assumption, process managers imho should not be statefull, therefore the axon’s naming thing properly. The process manager is basic event handler.
