In Event Storming, a technique used to model complex business processes and systems, the concept of a Command represents an intent to change the state of the system. It's an action that someone (typically a user or external system) wants to perform, which triggers an event in the system.

Here's a breakdown of the Command concept in Event Storming:

Key Characteristics of a Command:

1. Intent-driven: A command represents an intention to perform an action, such as "Place Order," "Create Invoice," or "Cancel Subscription."

2. Originates from an Actor: Commands are initiated by users, systems, or processes. They’re usually external requests, such as a user clicking a button or an external system sending a message.

3. Leads to State Changes: Commands typically lead to changes in the system’s state, and if successfully processed, result in one or more events (e.g., "Order Placed," "Invoice Created").

4. Decision-making Point: Commands are not always guaranteed to result in an event. The system processes the command, and based on validation or business rules, it might reject or accept the command.

Example of a Command in Event Storming:

- Command: "Submit Order"

  - Actor: A customer

  - Trigger: The customer has finished selecting items in their cart and clicks "Submit Order."

  - Process: The system checks if the items are available, verifies payment details, and confirms the order.

  - Outcome: If successful, it leads to an event like "Order Submitted" or "Order Payment Confirmed."

Visual Representation:

In Event Storming, commands are typically represented by blue sticky notes (or another specific color, depending on the convention used). Commands appear before the event they trigger, and they help tell the story of what actions users or systems initiate.

Relation to Other Concepts in Event Storming:

- Command vs. Event: A command causes an event if it succeeds, but an event is a record of something that has happened.

- Command vs. Aggregate: An aggregate (like "Order") often handles commands and enforces the business rules. For example, the "Order" aggregate might decide whether the "Submit Order" command is valid based on inventory availability.

Example Flow:

1. Command: “Submit Order” (user initiates)

2. System processes command

3. If valid, the system emits the Event: “Order Submitted”

4. Additional events like “Payment Processed” may follow based on system workflows.

Commands, therefore, play a central role in initiating change in a system and drive the flow of the model in Event Storming sessions.