Command

A Command is the expression of an intent to change the model. It is named in the imperative – StartRound, BorrowBook, CapturePayment – 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

In ESDM, a Command has exactly one publishing consistency unit. Most Commands target an Aggregate; some target a Dynamic Consistency Boundary or a Process Manager. 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 Publishes a Command

A Command is issued by an Actor, an External System, a Policy, or a Process Manager. ESDM tracks the issuers explicitly so the linter can verify that every Command in the model 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 linter can trace it across the model.

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.