Before writing a single line of code, we need to understand what actually happens in the business.
In the real world. When a customer does something, what does the business do next?
In the previous post we argued that the solution space your business needs to be discovered. If it is already known, you are building a commodity. Event Storming is how you discover it.
This is what that looks like in practice.
Why Event Storming for Arcadia Editions?
Arcadia Editions is a limited edition board game retailer. Scarcity is not a side effect of their business model. It is the core of it. When a new launch goes live, hundreds of collectors hit the site at the same time, chasing the same twenty copies of a hand-illustrated collector edition.
Trust is the product. A client who clicks reserve needs to know that copy is theirs until they finish. If it is not, they are gone. Not just from this launch. For good.
Event Storming puts business experts and technical experts in the same room to talk about exactly that. How do you build trust in the checkout process? What has to be true for a client to feel safe? What happens when it breaks?
What happens if two customers try to buy the last copy at the same time? What happens if payment fails after we already reserved the stock? What happens if a customer starts checkout and never finishes?
Discovering the Order Flow
We start with events. Things that happened, in past tense.
OrderPlaced. PaymentFailed. StockReserved. No database schemas,
no API specs. Just the story of the business told in business terms.
You sort them chronologically. And you pay attention to the pivotal ones. The events that mark a transition. A point of no return. Those are worth noticing.
Every event has something that triggers it: an intent, someone or something deciding to do something. That is what a command is. So we add them. One next to each event.
Commands are blue sticky notes. You place them just before the event they trigger. The board starts to read like a story. Command, event, command, event. A timeline of decisions and their consequences.
Then we look for what connects them. Between an event and the next command, there is always something. A business rule that says: when this happens, do that. That is a policy.
Policies are what hold the flow together. They are the business logic that was never written down. We all carry implicit knowledge about how we operate. Surfacing that knowledge is one of the most valuable things Event Storming does. And it is where the hot spots appear.
For every policy you discover, Alberto Brandolini suggests asking two questions:
- Does this rule apply always, or only in certain conditions?
- Does it apply immediately, or is there a delay?
When someone explains a business rule and you ask those two questions, the conversation starts. Every time. That is the point.
The flow we discovered
When a customer places an order, the first thing that matters is stock. Reserve it immediately. Not after payment. The moment they commit to buying, that copy is theirs.
But reservations cannot last forever. If payment is not completed, the stock needs to come back. That is the timeout rule. Hold it long enough for the customer to finish. Release it if they walk away.
And two customers can hit the same copy at the same millisecond. That is not an edge case for Arcadia. That is a launch day.
This is the flow we are building first. Stock reservation, timeout management, race condition handling. A solid foundation for a checkout process that collectors can trust.
From Event Storming to ZFL
This is where the ZenWave Platform enters the picture.
The findings of an Event Storming session live on sticky notes and photos. Useful in the moment, hard to share, impossible to version control. ZFL, the flow modeling language of the ZenWave Platform, gives those findings a home. A text format that captures commands, events, services, and policies in a way that is readable by humans and processable by tools.
In the next post we will walk through the full ZFL for the Arcadia Editions order flow. How we go from sticky notes to a versioned, shareable, machine-readable flow definition. And from there to AsyncAPI specs that describe every event in the system.
The full flow is already on GitHub at github.com/arcadia-editions.
Event Storming does not give you code. It gives you clarity. And clarity is what makes the code worth writing.