| It's certainly acceptable to start workflows explicitly! However it wouldn't be a good fit for the user signup process. 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. |
I love you. Will definitely give bus-workflow a thorough shot.
And a very last question if you could spare a bit more time..
Again the user signup & event flow,
When Workflow calls EmailService.sendEmail (given that the communication is via RPC and EmailService.sendEmail is an async operation that will resolve if the email was sent successfully), should Workflow wait for the sendEmail operation to resolve and complete the flow? Or should EmailService dispatches an event EmailSent so that Workflow can complete the flow?
This is a bit off the topic but I've been sticking with RPC style call rather than Events but still don't know yet what the best practice is.
Many Thanks