Not so fast. We need to follow a set of guidelines so we don’t end up with chaos. The value of Event Storming is communication, not just sticking sticky notes to the wall.

We’ll now introduce the core concepts involved in discussing and modelling event-driven business processes — events, reactions, and commands.

What’s an Event?

First, we’ll begin to think of our business processes purely in terms of events and reactions, which is a fancy way of saying “cause-and-effect”.

Things happen. Not all of them are interesting, some may be worth recording but don’t provoke a reaction. The most interesting ones cause a reaction. Many systems need to react to interesting events. Often you need to know why a system reacts in the way it did. — Martin Fowler, “Domain Event”

We can restate Martin’s quote as follows:

“Important events cause reactions elsewhere in the system, and it’s often important to understand why those reactions occurred”.

We can take that single statement as our guiding principle and use it to model, architect, and build an event-driven system.

Event Flows

A single event isn’t very exciting, so we need to consider events in term of flow — events over time. Orange stickies represent events. To model a business process we simply arrange events from left-to-right in time sequence. That’s it! Sounds simple? It is. That’s the point. There’s no unnecessary ceremony between you, your team, and an interesting discussion that yields results.

Once we have a linear sequence of events that occurs over time, we need to think about the cause of those events.

What’s a Reaction?

A reaction is something that needs to happen after something else happens. Reactions are best captured in the following statement,

“This happens whenever that happens”.

This is the reaction. That is the event. Whenever is the word that associates an event to a reaction to create a policy.

If you find yourself using the term whenever to describe a sequence of events, you’re speaking in terms of a event-driven system. The order of these statements is less important than the contents of the statement.

“Whenever a new user account is created we will send her an acknowledgement by email”.

If you read the above statement, the key is in the tense. Events are always past-tense, while reactions are always future-tense. More importantly, we never discuss “now” — we can’t make any assumptions about the current state of a system, because there’s no guarantee that what we intend to happen will actually happen. Mistaken assumptions are the root cause of most failures in computer systems. By modelling only cause-and-effect, we can better decide how to react to anything, because we’re not making false assumptions about outcomes — not only successful outcomes, but also errors and other less-than-ideal events.

What’s a Policy?

The flow of events and reactions together is called a policy — we call this flow a policy because the flow captures core business rules, such as “we need to alert a customer whenever someone logs into their account”.

A single event may cause multiple reactions. It’s also important to consider what happens when things go wrong. This entire flow can be considered an “account creation policy”.

It’s also important to note that a reaction — or an entire policy — doesn’t need to represent a piece of software. For instance, “confirm payment details” may be a manual process that involves an administrator manually verifying wire transfer details. The entire policy may even be implemented as manual processes rules, such as teams phoning each other rather than an automated computer system. Event Storming is an incredibly valuable technique to learn about manual processes in your organization as well as designing new software.

We also see that reactions often cause new events, such as a “fan-out” of reactions; a fan-out is when two or more effects emerge from the other side of whatever caused those effects. Event-driven systems are all about cause-and-effect, so it’s important to capture as many effects as possible. An event that causes a fan-out in this manner is probably worth diving into deeper, perhaps even worthy of its own event storming session.

Another reason to focus on policies is the importance of discussing and designing the process for when things go wrong; for instance, what happens if payment details are not successfully confirmed?