Edition 0 Updated to asp. Net core 0

The command class 
A command is a request for the system to perform an action that changes the state of the system. 
Commands are imperative, and should be processed just once. 
Since commands are imperatives, they are typically named with a verb in the imperative mood (for 
example, “create” or “update”), and they might include the aggregate type, such as 
CreateOrderCommand. Unlike an event, a command is not a fact from the past; it is only a request, 
and thus may be refused. 
Commands can originate from the UI as a result of a user initiating a request, or from a process 
manager when the process manager is directing an aggregate to perform an action. 
An important characteristic of a command is that it should be processed just once by a single receiver. 
This is because a command is a single action or transaction you want to perform in the application. 
For example, the same order creation command should not be processed more than once. This is an 
important difference between commands and events. Events may be processed multiple times, 
because many systems or microservices might be interested in the event. 
In addition, it is important that a command be processed only once in case the command is not 
idempotent. A command is idempotent if it can be executed multiple times without changing the 
result, either because of the nature of the command, or because of the way the system handles the 
command. 
It is a good practice to make your commands and updates idempotent when it makes sense under 
your domain’s business rules and invariants. F
or instance, to use the same example, if for any reason 
(retry logic, hacking, etc.) the same CreateOrder command reaches your system multiple times, you 
should be able to identify it and ensure that you do not create multiple orders. To do so, you need to 
attach some kind of identity in the operations and identify whether the command or update was 
already processed. 

---

274 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
You send a command to a single receiver; you do not publish a command. Publishing is for events 
that state a fact
—
that something has happened and might be interesting for event receivers. In the 
case of events, the publisher has no concerns about which receivers get the event or what they do it. 
But domain or integration events are a different story already introduced in previous sections. 
A command is implemented with a class that contains data fields or collections with all the 
information that is needed in order to execute that command. A command is a special kind of Data 
Transfer Object (DTO), one that is specifically used to request changes or transactions. The command 
itself is based on exactly the information that is needed for processing the command, and nothing 
more. 
The following example shows the simplified 
CreateOrderCommand
class. This is an immutable 
command that is used in the ordering microservice in eShopOnContainers. 
// DDD and CQRS patterns comment: Note that it is recommended to implement immutable 
Commands
// In this case, its immutability is achieved by having all the setters as private
// plus only being able to update the data just once, when creating the object through its 
constructor.
// References on Immutable Commands:
// http://cqrs.nu/Faq
// https://docs.spine3.org/motivation/immutability.html
// http://blog.gauffin.org/2012/06/griffin-container-introducing-command-support/
// https://learn.microsoft.com/dotnet/csharp/programming-guide/classes-and-structs/how-to-
implement-a-lightweight-class-with-auto-implemented-properties
[DataContract]