Using Event Storming to break up Monolithic Architectures

Our Story

Over the past few years, Dev9 has emerged as a leader in the Pacific Northwest region. Many of our clients have engaged with us to help make the transition from large monolithic applications to a more manageable distributed suite of smaller applications. Before Dev9 is able to start developing these microservices, we first need to learn and understand the business and the associated domains. Dev9 has used various methods to identify fissures between domains within a monolithic application, yet one method has stood out as the most complete process that achieves the majority of objectives for a Discovery engagement.

     How Dev9 Uses Event Storming

Dev9 has been utilizing Event Storming during our Discovery engagements so we can build comprehensive business flows in hours instead of weeks. The models discovered during our sessions are valuable to both the business and the development teams. After attending a session, it is very common for our clients to come away learning more about their own business processes,  establish business goal alignment, establish mutual business domain understanding and tease out business models allowing development to start with a domain driven design approach.

     What is Event Storming?

In the early 2010’s Albeto Brandolini developed a business modeling process built on the principles of Game Storming. He called this new process “Event Storming”. The core concepts of Event Storming were conceived from within the Domain Driven Development (DDD) community and combines the facilitated session aspects of Game Storming with the objective of identifying DDD principles. The primary goals of Event Storming are to promote transparency in the business flows, develop a model based on domain events, understand the system by asking the right questions, establish mutual understanding of the business flows and have fun through a truly collaborative process.

     Who is Involved?

While Event Storming is often used by technical teams, Event Storming is NOT a technology oriented activity. Business “Domain Experts” (product owners, stakeholders, marketing, sales and QA members) are typically the best source of domain events. The primary goal is to model the business domain, not to confuse the domain with the technology used to implement the business requirements.

     Our Process

Dev9 has found that a simplistic adoption of the Event Storming process refined by Alberto and the DDD community has proven to be the most beneficial. When planning and setting up an Event Storming session, we make sure that a good cross-section of the business is invited, domain experts come prepared to engage in conversation and hack the work environment.

     Hack the Environment

The session starts by hacking the room that the session is going to take place. This means moving chairs and tables away from the wall where the action is to take place. Next, masking tape is used to put up a long sheet of paper which will be the workspace for the team to add their work and draw context bounds. It is important to have more room than you think will be needed to accommodate domain events growing in all directions and possible re-starts should a model not be expressed as cleanly as the team would like. The following checklist are what we bring to every Event Storming session:

* A variety of sticky notes including orange, yellow, blue, green, purple and large yellow sizes
* Roll of butcher paper
* Box of sharpie or felt-tipped markers
* Masking tape
* Easel (Optional) and Poster-board with quick reference instructions
* Star stickers or small bookmark sticky tabs

     Set Very Basic Rules

Once the room has been setup properly, the team will start filtering in. Event Storming is unique in that each session is different than the last depending on the team and company. In order to get the most out of our sessions, we have discovered that using a very minimal set of rules and guidance allows for the flexibility teams need to model their business flows. We like to start by explaining that the session will be open and collaborative, no sitting or standing off to the side, and we are interested in modeling the business flows by using the most basic business elements called “domain events”. We cover a few terms for clarity and alignment purposes.



A specified sphere of activity or knowledge – Wikipedia Recipes, Billing, Customers, etc

Domain Event

Something meaningful that happens in the domain: “added ingredient”, “sent invoice”, “updated email” Lastly, we explain that Event Storming consists of teasing out a domain, modeling and visualizing user interactions, domain events, actions, aggregates & conditionals, bound context and describing read models. In a subsequent post, we will walk through a fictitious event storming session and describe an instance of how Dev9 conducts an event storming session.


In this post we have exposed one of the processes Dev9 uses to decompose monolithic applications into their business domain components.  We believe that a solid effort in each organization's understanding of the domain will pay off many times more than approaching a domain from a technology or database level. Remember, “Software development is a learning process; working code is a side effect.” – Alberto Brandolini