4 Comments
User's avatar
Artur Wojnar's avatar

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.

Expand full comment
Oskar Dudycz's avatar

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!

Expand full comment
Artur Wojnar's avatar

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.

Expand full comment
Jorik's avatar

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...

Expand full comment