Carrier
Part Four · Architecture Patterns
Chapter 161 min read

Workflow and Business Process Design

Enterprise systems do not only store resources. They run workflows. A claim is submitted, reviewed, denied, corrected, approved, and paid. A patient is referred, scheduled, checked in, assessed, treated, discharged, and followed up. Carrier workflows should make these business processes explicit.

Route-to-Action Workflows

The standard Carrier workflow pattern is route → action → transaction. The route exposes the operation. The action performs the business behavior. The transaction protects consistency. Enterprise architects should prefer named workflow routes for meaningful business transitions. Generic update routes are appropriate when the operation is truly simple, but they should not hide domain decisions.

Long-Running Processes

Some workflows cannot complete inside a single HTTP request: claims adjudication, bulk imports, report generation, external eligibility checks, data synchronization, referral routing, document processing. Long-running workflows require explicit design — a route may start the process, but the process may continue through jobs, events, schedules, or external callbacks. Carrier services should avoid pretending long-running work is just a slow request.

Jobs, Events, and Schedules

A job should represent a durable unit of work. An event should represent something that happened, not merely a command disguised as a message. A schedule should be owned by the domain that understands why the work runs. A client should isolate external system details from domain logic. Each construct should have a clear purpose.

Idempotency and Retry Strategy

Distributed workflows fail. Requests time out. Messages are delivered twice. Jobs retry. External systems return partial success. Users click submit again. Idempotency is the discipline of making repeated attempts safe. A good idempotency design defines how duplicate requests are recognized and what response is returned. Retry strategy should be explicit. Validation failures should stop. Temporary external failures may retry. Unknown outcomes require reconciliation.

Contents