workflow domain
a workflow is the shortest exact domain word for a durable, named process that coordinates work over time. it owns order, durable progress, waits, retries, and final outcome. it does not own the business implementation of each operation.
why
work that spans minutes, retries, and human waits cannot live inside a single request. orchestration, agent boundaries, durable handoffs, and approvals group because they all answer the same question: where does progress live while the process is not running. when that answer is a durable record, a crash costs one step; when it is memory, it costs the whole run.
when to use
this domain owns a decision when work spans minutes, retries, or human waits — ordering, durable progress, handoffs, and approvals. the smallest retryable unit belongs to the step domain; business rules belong to the domain service the workflow calls.
good and bad
bad
workflow: request handler calls every provider operation in sequence
retries and failures have no durable state or resumable ownership. when the handler crashes after three operations, all progress is lost — the workflow restarts from the beginning, causing duplicate work and unpredictable side effects. if a provider is slow, the caller times out with no way to check status or resume.
good
workflow: durable orchestration record → named steps → persisted outcomes
the workflow owns long-running progression while each step owns one effect. when a step fails, the workflow pauses at that step; retrying restarts only that step. a client can check progress anytime, and the system can resume after a crash or timeout. every operation is observable and replayable.