What is a System?

Event Storming is a collaborative modeling technique primarily used in software development to visualize complex domains, understand business processes, and gather requirements.

In the context of a Process Modeling EventStorming session, a System or External System (represented by a pink sticky note) is any automated component that acts as a black box of behavior. It is a place where commands are processed, business rules are enforced, and events are generated without direct, manual human intervention.

The "System" is a powerful abstraction. It allows the team to focus entirely on the business process flow without prematurely deciding who builds or owns the component.

Key Characteristics

1. A System represents a part of the process that is handled by software. It takes in information or commands and, based on a set of rules, produces an outcome (usually a domain event).
2. A Black Box: We intentionally do not look inside it. We only care about what goes in (Commands) and what comes out (Events). We are defining its role and responsibilities from the outside.
3. A Placeholder for Responsibility: It is a placeholder for a future implementation decision. By using a single color (pink) for all systems, we are explicitly deferring the crucial "build vs. buy" or "our team vs. their team" decision.
4. Source or Target of Interactions: A System either receives commands from a User or another System, or it publishes events that trigger other parts of the process.

Examples During Process Modeling

• A user Submits Order (Command).
• This command is sent to a pink sticky labeled "Order System".
• This system processes it and emits Order Placed (Event).
• The Order Placed event is noticed by a policy which processes it and based on the policy it might or might not submit another command, such as ReserveStock.

The Purpose of This Approach

Modeling this way is a strategic choice with a clear benefit: it keeps the entire team focused on mapping the end-to-end business process correctly. The conversation remains centered on "What needs to happen?" rather than getting sidetracked by "Who is going to build the inventory component?" or "Which third-party payment gateway should we use?"

Only later, during the Software Design phase, would you perform the "great sorting." You would look at all the pink System stickies and decide:

• Which ones will we build? These are "opened up" and their internal logic is designed, often being replaced by yellow Aggregate stickies. The "Order System" and "Inventory System" would likely become aggregates within your core domain.
• Which ones are truly external? These remain pink sticky notes, and the focus shifts to defining the precise API contracts for interacting with them. The "Payment System" (e.g., Stripe) and "Shipping System" (e.g., FedEx API) would remain as External Systems.

‍

‍