Good to know that this scenario is not excluded by design. Thank your for your answer and for creating an issue for my question. I will let you know if I end up implementing this.
What I am looking into is how this will work in a distribuded environment where saga1 and saga2 are two instances each living in a different cluster member. Most likely the two sagas will be of different types. If saga1 publishes a command that is targeted (handled) by saga2 then the framework should be able to figure out where to send the command since it will know in witch cluster member Saga2 lives (e.g from the hashcode of the saga id or the saga type). For events the framework must do something similar for each subscriber. I have not yet looked into how the distributed bus works but I assume this is more or less covered there. So I guess from a distribution point of view the problem og getting the commands and events to the right cluster member is the same. Is that a correct assumption?
The way I see it, this then boils down to how I design the message flow between saga1 and saga2.
Alternative 1: Saga1 can publish an event saying “I have done X” and hope saga2 will listen for event X and when it occurs then say “I have have done Y”. Furthermore saga1 can then listen for event Y and then say “I have done Z”.
Alternative 2: Saga1 can publish an event saying “I have done X” and in the same unit of work (transaction) send a command to saga1 saying (doY). Similarly saga2 will publish “I have done Y” and send command “doZ” to saga1. For this alternative it is of cause optional whether or not saga1 and saga2 publishes any events, but having the events there will make it simpler to add addtional (perhaps external) reactions to the main message flow. In this alternative I will also have to define command messages doY and doZ, which may or may not be needed for other purposes thus adding more code.
I guess it is a matter of taste, design philosophy and requirements that decides what works best in each case, the difference being that Alternative 2 has a more explisit main flow of messages. Since aggregate roots only send out events and no commands, it makes sense to start out designing the message flow for sagas according to alternative 1 as this approach then covers all cases and is already supported for the framework. Have I understood the overall design principle for alternative 1 correctly?
kl. 11:35:57 UTC+2 fredag 3. oktober 2014 skrev Allard Buijze følgende: