Event Storming

Once you’ve decided to find subdomains the DDD way, the practical question is: how do you actually come up with them?

Event storming is one approach teams use. Domain experts, developers, decision makers, and stakeholders sit together and whiteboard. Same session, different phases — not five different meetings.

What you do in the room

Rough flow:

1. Take out all events
2. Sequence them and find missing events
3. Decide bounded contexts for groups of related sequences

After boundaries are set, deriving candidate microservices gets faster — because you already know which events live inside which wall. That last step is usually outside pure storming, but it rides on the same work. See Bounded Context.

Dump events

Step 1 — dump candidate events on the board

Events are discovery fuel. Contexts — not sticky notes — usually become services.

Collect events (private → board)
        │
        ▼
Sequence + find missing / branches
        │
        ▼
Group related sequences → bounded contexts
        │
        ▼
Contexts → candidate microservices

Activity 1 — dump the events

Everyone thinks of events on their own first. Write them down privately, then put them on the shared board.

For a chat-style app, a starter list might look like:

• User registered
• User logged in
• Message sent
• Message delivered
• Message read
• Message deleted
• Message edited

Some events will be wrong. Some will be out of scope for v1. That’s fine — you’re collecting candidates.

Activity 2 — sequence and find gaps

Still the same whiteboard session. Order the events. Look for holes and alternate paths.

Example: after login, logout is an obvious missing event. Paths aren’t always a single straight line either — someone might delete a message before it was delivered. Someone might send a message and log out before delivery finishes; the server still delivers.

Re-walk the board. Parallel paths are normal. The point is a shared picture of “what happens in this product,” not a perfect flowchart on the first try.

When not to use this

Skip a full storming workshop if the product is tiny, the domain is already well modeled, or you only have engineers in the room. Without domain experts, you mostly invent events that match the current code.

Also don’t treat storming as a one-shot ceremony that freezes forever. New events will appear later — you check whether they fit an existing context or need a new one.

Production pitfall

Turning every sticky note into a microservice. Events are discovery fuel. Bounded contexts — groups of logically related events — are the unit that usually becomes a service. If you skip the grouping step, you get a chatty mesh of nano-services.