Commands
A command expresses one business intent to change aggregate state. Define its payload and target aggregate first, then send it through an in-process CommandGateway, an aggregate HTTP route, or the global command facade, and wait only for the completion stage the caller actually needs.
A command starts as business intent and connects to downstream collaboration through durable facts and observable completion signals.
Quick Paths
| Goal | Entry point |
|---|---|
| Define and send a command | Read Define Commands, then Send Commands |
| Call another service | Use the API Client with the global command facade |
| Choose a completion stage | Read Completion Semantics |
| Diagnose timeouts, duplicate requests, and downstream failures | Read Failures and Idempotency |
Application Use
- Use Define Commands to establish the payload, target aggregate, and handler.
- Use Send Commands to choose among the local Gateway, aggregate routes, and the global facade.
- For service-to-service calls, use the API Client and accept its current final-result-only boundary.
- Use Completion Semantics to choose the earliest stage that satisfies the response contract.
This track answers how an application invokes commands. It does not expand Dispatcher, Filter, WaitState, or notifier internals.
How It Works
To understand the runtime, start with Command Processing Pipeline, then read Command Wait Runtime and Command Transport and Routing. They own the sequence from Gateway through aggregate processing, event append, and stage signals; application pages consume those results without duplicating the state machine.
For failures, return to Failures and Idempotency and collect evidence by commandId, requestId, aggregate identity, stage, and error code.