Command Context Consistency
Command Context Consistency is the rule that a command's outcome is recorded only while the facts its decision relied on still hold.
A command reads a context: the facts relevant to its decision. It decides against that context. Between the read and the write, another command may change one of those facts. Command Context Consistency requires that the outcome is not committed on a context that has changed.
It follows the split between commands and queries. A query only reads, so it has nothing to protect. A command changes the domain, so its decision must still be valid at the moment it commits.
The Consistency Boundary Is the Context
The boundary of consistency is the command's own context: the exact facts the decision read.
It is not an aggregate. It is not an entity. It is not a table or a stream chosen in advance.
Two commands that read different facts do not conflict, even when they touch the same entity in a data model. Two commands that read the same fact conflict only on that fact.
This replaces entity-centric thinking. A command does not load an object graph or lock an aggregate to be safe. It protects the facts its decision used, and nothing more.
Realizations
Command Context Consistency is an obligation. How it is met depends on the store.
In a relational store, the command reads its facts under a shared lock and writes under constraints. A fact defined by the absence of a row, such as an unbooked night, is guarded by a unique constraint. A conflict at commit surfaces as a business rejection.
In an event store, the command records a context version when it reads, and commits with a conditional append that succeeds only if that version is unchanged. This is defined by the Command Context Consistency specification.
Both meet the same obligation: the outcome is not recorded after the basis for the decision has changed.
Not an Aggregate, Not a Lock on Everything
A predefined aggregate fixes one consistency boundary for every command that touches it. That boundary is larger than some commands need and smaller than others.
Command Context Consistency lets each command declare its own boundary through the facts it reads. Consistency follows the decision, not a shape chosen before the decisions are known.
Where It Lives
The command reads its context and commits its outcome inside the Request Processing Unit that owns the capability, against the Application State.
The check and the commit are one atomic step. A conflict is a business situation, mapped to a rejection, not a technical error.
Summary
Command Context Consistency is:
- the rule that an outcome commits only on the context it was decided from
- a property of commands, not queries
- scoped to the facts the decision read, not to an aggregate or entity
- met by locks and constraints in a relational store, or a conditional append in an event store
- specified as an event-store contract in the Specifications section