I was missing in your previous Decider example an option that the input can also be an event and that case is covered here, nicely described with TS.
I feel this slight difference between Decider and Workflow - in the latter due to explicit integration patterns (send, publish etc) we can (explicitly) define our intention. That was struggling me a bit with the decider that I was about to publish output events and also initiate an action by sending a command.
Yup, Decider pattern is for handling the business logic. Workflow pattern is about handling and coordinating business processes. They're playing nicely together, but are a bit different. Decider always takes command and state, and returns events. Workflow pattern is usually triggered by event and typically returns command. That's of course not a hard rule, but a thumb rule.
So I'd typically use Decider for the business logic and if I need to coordinate multiple pieces of business logic, I'd use Workflow as "glue". Workflow could be triggered by the events created by the business logic.
I feel and see the difference - what you've implemented by the Workflow Pattern is actually an Orchestreted Saga.
But the problem I encounter is that presumably Decider is not about consuming events as the input. That might be situation where I do things wrong way, but I've had cases where I wanted to utilize events as "commands" in my services.
So, the Workflow pattern with its transparency of integration patterns seems to be also a valid option of handlig a domain logic, but with the risk of messing up the business logic with application layer I guess.
I also see cases where I'd like to send a command as a result of processing a command along with events. Maybe it's all about splitting the business logic out of that process into a separate Decider flow, but still... it seems to be part of next iterations of working od the code and also it feels a bit academic consideration.
To see if I understand it correctly: a saga in this webinar listens to internal entity events, and published commands based on them, right? So basically _all_ internal entity events are automatically published in the application.
One thing that I didn't like too much is that you need to add the GroupCheckoutId to the GuestStayAccount events/command, but I wouldn't know a better alternatief myself...
Nice one.
I was missing in your previous Decider example an option that the input can also be an event and that case is covered here, nicely described with TS.
I feel this slight difference between Decider and Workflow - in the latter due to explicit integration patterns (send, publish etc) we can (explicitly) define our intention. That was struggling me a bit with the decider that I was about to publish output events and also initiate an action by sending a command.
Yup, Decider pattern is for handling the business logic. Workflow pattern is about handling and coordinating business processes. They're playing nicely together, but are a bit different. Decider always takes command and state, and returns events. Workflow pattern is usually triggered by event and typically returns command. That's of course not a hard rule, but a thumb rule.
So I'd typically use Decider for the business logic and if I need to coordinate multiple pieces of business logic, I'd use Workflow as "glue". Workflow could be triggered by the events created by the business logic.
Thank you for the feedback!
I feel and see the difference - what you've implemented by the Workflow Pattern is actually an Orchestreted Saga.
But the problem I encounter is that presumably Decider is not about consuming events as the input. That might be situation where I do things wrong way, but I've had cases where I wanted to utilize events as "commands" in my services.
So, the Workflow pattern with its transparency of integration patterns seems to be also a valid option of handlig a domain logic, but with the risk of messing up the business logic with application layer I guess.
I also see cases where I'd like to send a command as a result of processing a command along with events. Maybe it's all about splitting the business logic out of that process into a separate Decider flow, but still... it seems to be part of next iterations of working od the code and also it feels a bit academic consideration.
Love the event sourcing webinars!
To see if I understand it correctly: a saga in this webinar listens to internal entity events, and published commands based on them, right? So basically _all_ internal entity events are automatically published in the application.
One thing that I didn't like too much is that you need to add the GroupCheckoutId to the GuestStayAccount events/command, but I wouldn't know a better alternatief myself...