State transitions should encode proof boundaries.
domain-driven design
Praxis for Domain-Driven Design
A domain model should preserve the promise, not just name the nouns.
Start in the practice language people already use. Then use Praxis to distinguish the signal from the promise, the carrier from the capability, and proof from the status label.
Diagnostic move
Translate the practice into promise work.
A domain event named RefundIssued may be technically true inside one bounded context and false as a customer-facing promise. Praxis forces the model to separate internal state, public signal, proof, and repairable promise.
The question is not whether the familiar artifact exists. The question is whether that artifact witnesses the promise people actually rely on.
- Signal
- The label, state, event, journey step, or metric that says something happened.
- Promise
- What someone treats as true because the product signaled it.
- Carrier
- Where, through whom, or through what the promise was encountered.
- Proof
- Evidence that would matter to the relying person, not only the internal system.
- Repair
- The owner and path when the promise cannot hold.
Translation
How Praxis enters this practice.
Aggregates should not emit promise labels before invariants hold.
Ubiquitous language should distinguish signal from promise.
Signals to inspect
Start with one label.
approved
reserved
issued
settled
Worksheet
Keep the review concrete.
Download the worksheet, choose one signal, and write the proof and repair path before discussing the theory.