Up to here, sales reacts to QuoteAccepted by winning the deal. After an acceptance, though, the office wants more: to propose a kick-off
appointment and to send the customer a confirmation that a person checks beforehand. Three contexts, a deadline, and steps that can
fail. Who keeps track of which step is done and what to do when one doesn't work? In this lesson the flow gets someone of its own
responsible for it: a process manager.
Choreography or orchestration
For a flow across several contexts there are two ways to build it:
- Choreography: Every context reacts to the events of the others and publishes its own. Nobody steers, the flow emerges. That is how the Kladde has worked since 4.3.4: Quotes report “accepted”, sales reacts.
- Orchestration: A process manager (orchestrator) knows the flow. It reacts to an event, sends commands to the participants, remembers their progress and decides what happens next, even when something goes wrong.
| Choreography | Orchestration | |
|---|---|---|
| good for | few steps, no shared deadline, no taking back | many steps, deadlines, compensating steps |
| overview | spread across all participants, hard to see | in one place, in the state of the process |
| coupling | loose, but cyclic dependencies loom | the participants don't know the process, the process knows them |
| testing | one run needs all participants | the process alone, with fake participants |
| risk | “Who actually does what if …?” | the process manager as one more place that can fail |
Microsoft's saga pattern describes both forms with these trade-offs. A rule of thumb: As soon as somebody has to ask “and if step three fails, who gives step two back?”, the flow needs an orchestrator.