So basically for the saga persistence we can have either event
sourcing (command is saved along with the events in the transaction)
or simple state storage (command is saved along with the latest state
and possible outgoing events). Dispatcher could dispatch in async
later in both cases.
Once we have command info persisted atomically with the resulting
changes, we can have all the idempotence we need (still staying away
from the 2PC). Consistency is 100% even if process dies between the
commit and ACK.
So technically sagas are just like the aggregates (they are entities),
and the primary difference is in the intent (similar to the difference
between commands and events) and life span expectations.
This way everything that happens in saga between the handler and
message dispatch is rather straightforward, reliable and simple (and
similar to the aggregate behavior).
Thanks again for helping to think though the logic of this part of CQRS!
Best regards,
Rinat
However, implementation logic of command handlers outside of these
"inner" specifics seem to be similar for both cases (i.e.: questions
of reliability, 2PC, transactions and message dispatch). Don't you
think?
Best regards,
Rinat
I'm using Esper for my "sagas" and currently I can rebuild it's state
by replaying events at startup.
Esper allows one send timetick events to control the flow of time when
replaying in isolation, and it's pretty awesome!
(regards)
Thanks a lot for the lead!
Esper definitely looks interesting. Although I'm not sure that's a
perfect fit for sagas in my projects, but the ability to run
continuous event queries is really something I would love to try
(currently we cache all events locally and run manual LINQ queries
printing results to Excel via OpenXML).
Best regards,
Rinat
I've published an article that goes into some deeper on Sagas (as per
discussions in this thread and outside of it).
Although there is still no source code, but it might help to
understand everything.
Just a caveat: I'm sorry for going into deep details about the
partitioning logic (this was needed by the specifics). In practice
implementations will probably skip this part completely in 95% of
cases (and go lightly on a few other explicit constraints as well).
Best regards,
Rinat