Design an actor boundary

Use an actor when a responsibility benefits from owning state and handling requests through a defined contract. Start with the invariant you need to preserve, then place the boundary around the state required to enforce it.

The example below is a design exercise. Names describe domain roles, not declaration syntax.

1. Name the invariant and its owner

For Inventory, the invariant might be “a reservation must not exceed the stock available to this account.” Inventory owns the relevant stock and reservation state. Checkout owns the order’s progress.

Avoid splitting the invariant across two actors that can each independently write half of it. Ask whether the state must change together, who decides, and what outcome the caller needs.

2. Define the request and outcomes

Write down the minimum request: an account context, item identity, quantity and request identity if retries need one. Make successful reservation, insufficient stock and invalid input distinct outcomes where the domain needs that distinction.

The authenticated account context must come from a trusted ingress or established authority context. A caller-provided account field is data; it is not proof of identity.

3. State each communication direction

Checkout requests a reservation from Inventory. Inventory returns the reservation outcome to that interaction. A later stock notification, if needed, is a separate operation with its own contract.

This avoids treating a reply as unrestricted permission to call the original requester.

4. Assign the narrowest useful authority

Describe which subject may request which operation, on which target, in which account or resource scope. Keep that grant separate from the source declaration.

Ask your agent to show an allowed request and a request that should be refused. The refusal should follow the actual admission path, rather than an unrelated validation branch that happens to produce an error.

5. Decide what must survive

List the durable state and meaningful wait points. Specify what happens if a process stops after accepting a reservation but before the caller receives a result. Keep external-provider delivery questions separate from local actor recovery.

If a future source change alters saved state, identify the conversion it would require. Durability makes state compatibility an explicit design concern.

6. Review the topology

Compare declared relationships, permission in the chosen context and retained observations. Check dynamic targets and inspection coverage. The absence of an observed edge does not establish that an interaction is impossible.

Keep the first version inside one runtime if that suits the workload. Separating domain responsibilities is useful before deciding whether any of them need independent deployment.

The resulting design should let someone answer: “This actor owns this invariant; these subjects may request these changes; these effects cross its boundary; this state survives interruption.”