Command

A Command is the expression of an intent to change the model. It is named in the imperative – BorrowBook, CapturePayment, ReserveSeats – and it targets exactly one consistency unit.

Where an Event records what happened, a Command requests what should happen. The Command can fail. It can be rejected by an invariant, refused by a permission check, or ignored as a duplicate. Only when it succeeds does an Event come into being.

Single Target

A Command has exactly one target. Most Commands target an Aggregate; some target a Dynamic Consistency Boundary. The rule that a Command targets a single unit is what keeps the consistency story tractable. A Command that wants to change two Aggregates is not really one Command; it is two, and the model is more honest if you write them that way.

Who Issues a Command

A Command is issued by an Actor, an External System, a Policy, or a Process Manager. The model tracks the issuers explicitly: every Command has at least one source.

A Command without an issuer is a Command nobody can send – almost always a modeling mistake.

Data and Identity

A Command carries a payload – the data the consistency unit needs to honor the request – and an identifier for the target unit. The payload is whatever the domain requires; the identifier is the same natural key the target uses for its own identity, so the link between Command and target is unambiguous.

Commands do not carry results. The result of a Command is an Event (success) or a rejection (failure); neither is encoded in the Command itself.