designing-workflow-pipelineslisted

# Designing Workflow Pipelines ## Overview A workflow is one business process: a command arrives, work happens, events come out. Modelled as a pipeline, it becomes a sequence of small total functions, each with its own input and output types, composed into one function whose signature states the whole contract. This shape is what makes a domain model executable. The types along the pipeline record which checks have already happened, so no step re-checks; the ends of the pipeline mark exactly where effects are allowed; and the whole use case can be read in one place instead of being assembled in a reader's head from four services. ## When to use - Implementing a use case, endpoint handler, job, or message consumer - Business logic for one operation lives in three files - A service method is long and mixes validation, rules, and I/O - Deciding what the steps of an operation are - Turning an event-storming result into code Not for: designing the data itself, which is [modeling-with-algebraic-types](../modeling-with-algebraic-types/SKILL.md). ## Core rules 1. **Start with the end points.** Write the workflow's own signature before its steps: command in, `Result` of events out. 2. **One type per stage.** The output of a step is a type that did not exist before it ran, so later steps cannot receive unvalidated data. 3. **Each step is total.** Everything that can go wrong is in the return type. No exceptions, no nulls, no hidden failure. 4. **Effects at the ends onl