EventStorming: A Smooth Start into the Workshop
Real-world tips for facilitating domain modeling and system design that get devs and business working together productively
EventStorming and Event Modeling are great techniques to collaboratively explore domains and design (event-driven) systems. However, getting started can feel awkward at first. That’s why I want to share my experience - what helped me get over the initial hesitation so that everyone can benefit from the workshop.
Why So Many Sticky Colours?
The full set of stickies used in both EventStorming and Event Modeling can feel overwhelming in the beginning. But especially if the goal is to start exploring a problem domain with everyone involved (like developers, business reps, stakeholders), all we actually need are Domain Events.
The best discussions often emerge when we start jotting down what we believe is happening in the domain using Domain Events, placing them on a Timeline that shows which event comes after which. That’s it.
These discussions naturally surface misunderstandings and help align everyone’s mental model. This alone can massively improve collaboration and reduce friction once development starts.
We should only introduce more stickies if there's a clear need. The logical next stickies are Actors and External Systems, since someone or something needs to trigger those Domain Events.
What is a Domain Event?
A common source of hesitation is the term "Domain Event" itself. Workshops often start with something like, “Let’s collect all the events that can happen in our domain.” But this can immediately raise questions like: “What do you mean by an event?”, “Why are we talking about things in the past?”, or just a general “This feels weird.”
It’s not always easy to explain what a Domain Event is. But here’s something that’s worked well for me in many cases: a Domain Event represents something meaningful that has already happened in the business domain. It’s something that the system (or others) might want to react to.
For example: A user submits an address form. After the address is successfully stored, we publish an event like “AddressSubmitted” to inform other parts of the system what happened. That’s a Domain Event.
Of course, not every Domain Event needs to involve a state change, but thinking of them as the result of some meaningful outcome helps people get started.
Use Domain Language, not CRUD
We’re all conditioned to think in CRUD terms: Create, Read, Update, Delete. But when we model using Domain Events, that mindset gets in the way.
Even business stakeholders might talk in CRUD terms because they've absorbed our technical language. That’s why we need to be intentional about using the domain’s own language during these workshops.
Take “AddressSubmitted” for example. A CRUD mindset might have started with Domain Events named “AddressCreated” or “AddressUpdated.” But such names lose important context. If someone updates their address because they moved, why they moved might affect what the system needs to do next.
A concrete example might be a Swiss tax system. Here, different rules apply depending on whether someone moved within the same municipality, to another one, or abroad. So instead of just “AddressUpdated,” we might model each Domain Event separately as:
MovedWithinMunicipality
MovedToAnotherMunicipality
MovedAbroad
This makes the system clearer, more explicit, and easier to evolve.
Domain Events for Different Granularities
Sure, we could just emit a general “AddressUpdated” event and let downstream systems figure out whether it was relevant for them or not. But that leads to unnecessary complexity and wasted computation. Having more explicit Domain Events generally keeps things cleaner and more maintainable.
The granularity of Domain Events isn’t a hard science. It depends on your domain, your team, and how the system is supposed to behave. The key is to let the discussions guide the granularity, and be okay with evolving it over time as your understanding deepens.
Event Modeling / Storming is Agile
In general, these workshops are not meant for Big Design Up Front. They work best when used with an agile mindset: increment → feedback → iterate.
We want to collaboratively build a shared mental model of the business domain. There are no absolute “rights” or “wrongs.” Each round of discussion improves the model.
The more questions we raise during an initial session, the better. They signal gaps in understanding, which are perfect opportunities for exploration and experimentation.
These models are lightweight and often inaccurate in the beginning. But that’s fine. Real clarity tends to emerge once implementation starts, iteratively.
Some teams have tried using these techniques to plan 3 years of development in advance and were disappointed with the result. That’s not surprising as it contradicts the agile spirit these workshops are built on.
LLMs in Collaborative Workshops
One final note: I do believe that AI tools like LLMs can actually support a more iterative and collaborative approach.
They let us cheaply experiment with ideas, generate working examples, and validate flows without needing to build full mockups that rarely reflect real product behaviour anyway.
Even better, consulting LLMs regularly helps speed up decision-making. We no longer have to awkwardly piece together everyone’s fragmented knowledge but can use AI as a thinking partner to get clearer, faster.
This is one of the most exhausting parts of traditional workshops: everyone trying to explain their fragmented understanding, often in inconsistent ways. LLMs might help bridge those gaps if used thoughtfully.
I’m genuinely hopeful that AI will improve how we collaborate and ultimately lead to better software that solves real problems, faster and cheaper.
Let’s see where it takes us :)
Want to learn more?
Curious to go deeper?
Our O’Reilly course “DDD, EventStorming, and Clean Architecture” extensively covers both Big Picture EventStorming and Design-Level EventStorming for you to get started with the topic in more depth.
We also provide remote, hybrid, and on-site workshops on EventStorming, either exclusively as a deep-dive or integrated into the wider context of collaborative software development.
Check it out! :)