When developing software, it’s often hard to keep track of all the things you need to plan for. It becomes especially hard if you’re designing something from scratch and you want to understand how all the moving parts will interact with each other.

To get around this kind of difficulty, we recently tried out Event Storming. Mariusz Gil, who is a great software coach and trainer, showed us how to organize an Event Storming Session on the example of our new Developers Program (our domain, but more on that later).

The session started with a single post-it note which had: “App installed” written on it, which represented the first event in our project. As the session went on, the number of post-its notes quickly grew, slowly showing us how the new Developers Program could look like.

Domains and Domain Events in Event Storming

But first things first. What is a Domain in software engineering? One of the simplest definition states: “Domain in software engineering is a sphere of knowledge.” It is a field of study that defines a set of common requirements, terminology and functionality for a software program constructed to solve any problem in a given field.

The critical complexity of most software projects is in understanding the domain itself.

~Eric Evans

During an Event Storming session, you create Events in a specific domain, just like our “App installed” event. Here are a few examples of Domain Events:

• A step in a business process like “application created”, “application installed”, “developer account created”,
• Something that happens on a scheduled basis like hourly “application health checked”,
• Something meaningful that occurs as a result of something else happening like application being accepted after review the process has been completed.

Where do Domain Events come from? Basically, events may come from:

• Action started by a user,
• External System,
• As a result of the passage of time,
• As a consequence of another domain event.

Hot to get started with Event Storming

The key things you need to do before an Event Storming Session:

• Invite the right people,
• Provide unlimited modeling space.

Each person must have their own post-it notes and a marker to write with. The first step (we called it wide exploring) is just like a brainstorm. In this step, everybody should write and post on the board all the Events that may have a place in the modeled system. This is also the only phase when people may work independently. This will create the basis for further exploration.

The next step is placing Events on a timeline and exploring the Domain by asking the clarifying questions. Here are a few examples:

• “What is the context of …?”
• “What was the path that led us here?”
• “What is a good example of …?”
• “What else might happen?”

The board will quickly fill up with post-it notes. It is a great way to visualize all the stuff you’ve collectively learned, for example noting all the assumptions you’ve made, any problems you can think of and how the value stream will look like.

What you can get out of Event Storming

After a few hours, hundreds of questions, discussions, moving and removing plenty of post-its notes we got a result: an easy to understand model of our Developers Program system. And the best thing about it? You don’t need technical skills to understand it.

For me, the biggest advantage of the Event Storming session is the easy way it offers to catch plenty of possible issues (functional, logical, business) and fix them in the earliest stage, way before you have the need to invest any resources or time into them.

According to the “1-10-100 rule”, we were able to save a lot of work time this way. This picture shows how many unnecessary discussions, implementations, possible bugs we avoided.

We found Event Storming to be an engaging, efficient and easy way to understand the domain and to tackle a large project without missing anything. I strongly recommend giving it a try the next time you’ll face a big software project that you need to think out thoroughly.

If you want to learn more about Event Storming, here is a great presentation by Paul Rayner.