Commands and Queries
A domain request is either a Command or a Query.
The two are kept separate. A capability is a command capability or a query capability, never both.
Command
A Command asks the domain to decide, and it may change the domain.
It produces an outcome: success with the consequences that were recorded, or a rejection with a business reason.
A rejection is a valid outcome. The domain understood the request, evaluated it, and decided it could not happen. A rejection is not a technical error.
Because a command changes the domain, its decision must still hold when it commits. See Command Context Consistency.
Query
A Query asks the domain a question.
It returns the requested result. It does not change the domain.
A transformation of domain facts that the caller needs belongs inside a query, not outside the domain.
Why They Stay Separate
Deciding a change and answering a question are different responsibilities.
A command carries the rules, the consistency protection, and the recorded consequences. A query carries none of that; it only reads and returns.
Keeping them apart keeps each capability focused, keeps reads free of side effects, and lets a command and a query for the same subject change for their own reasons.
Implementation
Each Command and each Query is one Domain Capability, implemented by one Request Processing Unit.
A command RPU owns the complete path that can change the domain. A query RPU owns the path that reads it. Neither calls the other.
Summary
- a domain request is a Command or a Query
- a Command decides and may change the domain, and returns success or a rejection
- a Query answers a question and returns a result, changing nothing
- a rejection is a business outcome, not an error
- commands and queries stay separate, each its own capability and RPU