| Thank you very much for your reply!
I wonder if the flow can start from Workflow not from UserService. E.g.,
1. Browser requests with UserSignup event (or API gateway receives it, do not call UserService but emits event) 2. Workflow receives the event, then calls UserService.signupUser activity 3. UserService creates a user then return the call back to Workflow 4. Workflow resolves the call(singupUser) then calls EmailService.sendEmail 5. EmailService.sendEmail sends an email then calls back to Workflow 6. Workflow resolves the call(sendEmail) then the flow is completed The difference is that Every workflows will be defined inside Workflow and Services won't serve requests directly, which I believe this gives a complete view to the flow. However there must be something that I'm missing here since what I'm describing seems like an anti pattern. |
In the above example, the user just wants to signup. They don't care about receiving a welcome email or being subscribed to a mailing list or anything else, they just want to register an account. That's a pretty good use case for just `POST /signup`, that hits the user service and spits out an event that the user has signed up.
Starting a new workflow when that event is published makes sense in this case.
An example when a workflow is started explicitly could be something like doing a fire system test. You could:
1. shoot off a command that starts the FireSystemTestWorkflow
2. the workflow sends a bunch of commands to test sensors and sirens
3. those things publish events that they're functioning correctly
4. the workflow waits for all of these events to come back
5. the workflow publishes a FireSystemTestedSuccessfully event
The nice side of this is that the workflow can respond if a sensor or siren fails and does what's called a "compensating action", ie: compensates for the deviation of the successful path by performing a corrective action like sending a command to start the device or notify a technician.