Commands

In comparison to the Events, Command represent a request for a change in application state. Before raising command, parameters should validated so the command most likely succeeds.

The command is as POCO-style class that contains parameters required for change the state. Every command type must have exactly one handler responsible for executing the business logic. As in Events commands are post through ICommandDispatcher facade and handled by registered ICommandHandler.

Paralel command execution

In terms of the CQRS a dispatcher should handle the paralelity of command handling. This can be solved at three levels:

1. In basic implementation, all required for a change in an application should be executed in serial manner. This guarantees the ACID behavior.

2. When your application needs more throughput, you can design which command types can execute in paralel. Simply "making an order" and "publishing a text description on a product" shouldn't interfere.

3. You can design which command of same type, but with different key parameters, can execute in paralel. An "order for product A and B and other order for products C and D" can be executed in paralel, because the capacity of both are separated. But when one product is in two orders, these shouldn't be executed paralely. These rules can be more complicated, but the principle remains.

Scalability