search

simplesourcing / simplesagas

Simple Sagas is a library for building process coordinators for distributed systems based on Kafka Streams
Apache License 2.0
20 stars 5 forks source link

Dynamic Sagas #25

Open szoio opened 5 years ago

szoio commented 5 years ago

Saga definitions are currently static as a design choice for simplicity. Should this capability be extended to include dynamic Saga definitions. This is a fundamental feature that would need some discussion. Possible options:

  1. Some kind of dynamic saga language.
  2. (Simpler) have some kind of Saga action that can rewrite (part of) the saga graph.
  3. (Simplest) cater for many of the same use cases via sagas within sagas (https://github.com/simplesourcing/simplesagas/issues/24). E.g. branching/conditional sagas could probably be handled this way.
justin-tomlinson commented 5 years ago

Id be interested in this enhancement, Im looking at simple sourcing and importantly simple sagas for a new application we are building. part of the application is modelled around general journal entries. The requirement is for a dynamic set of debit/credit pairs to complete as an atomic unit. Open to suggestions if this can already be catered for in the current libraries

szoio commented 5 years ago

I think you wouldn't need a dynamic saga for this. You could have a saga consisting of a debit and a credit, and if either fails, the other is reversed.

justin-tomlinson commented 5 years ago

but if the number of debit and credit pairs within a single "journal" are not known, would this still apply? For example if I want the below journal examples to occur. In our initial modeling, the credits are acting as disbursements of the single debit amount. The number of and disbursement amount would be determined by applying a configuration provided by an upstream service.

scenario 1:

account DR DR
1 13.00
2 10.00
3 1.50
4 1.50

scenario 3:

account DR DR
1 100.00
2 50.00
3 25.00
4 15.00
5 5.00
6 5.00
szoio commented 5 years ago

Yes, this would work fine. This level of dynamism is supported already. The saga (i.e. the saga graph) is defined at the client side at run time. In scenario 1 you'd create a saga that debits account 1 and credits 2-4. In scenario 3 you'd create a saga that debits account 1 and credits 2-6 etc. As long as the saga coordinator knows about credits and debit actions it should work. You'd only need a dynamic capability (as in this issue) if the some of the saga actions need to know what the outcome of previous actions were in order to be able to execute.

justin-tomlinson commented 5 years ago

interesting..ill keep plugging away then :)