Build a Request and Response flow
Ask for availability, return a structured Response, and preserve both logical correlation and exact causality.
Requests and Responses make business communication machine-readable without forcing every interaction into an RPC model. A Request can ask for work, information, approval, or a proposal. A Response answers one exact Request occurrence.
Start with two participant Channels#
Use a Vet Order with a customerChannel and vetChannel. Each Channel binds a provider-backed Timeline and actor to one role in the document.
The Channel binding—not a claim inside the message—determines who contributed the action.
Emit a structured Request#
Maya requests available visit slots. The Request uses requestId for application correlation, threadId for the wider conversation, and recipientChannel to direct attention to the vet.
Addressing does not make the Request private. Visibility still follows the enclosing document and access policy.
Answer the exact occurrence#
The veterinarian writes a Response on the vet Timeline. inResponseTo points to the exact Request node, while the shared requestId and threadId make the flow easy to group in a UI.
One Request can receive several Responses: an acknowledgement, progress updates, alternatives, and a final result.
Update the shared state#
The Vet Order processes the Response, adds the offered slots, and emits a domain event such as Visit Availability Recorded.
The conversation and the state transition now share one causal trace. There is no separate opaque RPC log to reconcile later.
Distinguish a Response from an Operation#
A Response can report information without exercising another participant's authority. An Operation Request names a callable operation and effective Channel and can change state when eligible.
Do not turn every reply into an operation, and do not treat human Chat text as a structured Response unless the document explicitly defines that behavior.