Schedule a Call

Event Storming - Lessons Learnt From The Trenches

At Rubicon Red, as part of custom application development, we are often called upon by our customers to solve complex business problems. This involves building platforms out of existing assets, modernising legacy solutions and providing API remediation work to unleash their innate innovation capability. Existing software assets typically comprise of legacy monoliths, hand-coded integration to 3rd party systems, complex business processes and an enormous entity model that can easily fill a few walls, when printed.

As the team embarks on their journey to understand the complexity of an existing system, the size of it and lack of updated documentation can make the business process discovery difficult, laborious and often error-prone. Knowledge about such complex applications often resides in organisational pockets following Conway's Law. Lack of access to all relevant parts forces the team to visualise an incomplete capability model for the existing system. Naturally, this results in the formation of an incomplete requirement specification, and ultimately a buggy, incomplete, unusable and unstable piece of software, out of it.

As trusted advisors, we take care of such a possibility at an early stage. We put great emphasis on the discovery phase and use techniques to find hidden nuances so that we can draw a more holistic picture of the system upfront.

Event Storming helps us do exactly that. In this blog post we have explained how we applied the Event Storming technique in one of our recent engagements and what we discovered during our journey. Hopefully, this will provide some valuable insights that might help you apply this technique successfully, in your own environments. In this blog we'll cover:

Why Event Storming?

One of the key artefacts produced out of analysis work is a Capability model of the system (“existing” and/or “to be”).  Event Storming helps with the identification of capabilities. Capabilities are realised via one or more modules within the system. The sizing for capabilities is important, as when designed too fine-grained, it causes a lot of internal chattiness between modules, and on the opposite spectrum (when capabilities are designed too coarse-grained) it causes a high degree of coupling. Event Storming helps us discover the right scope and size of a capability - and also exposes the relationship between them.

One can argue that many established approaches such as Business Capability Modelling already exist for similar purposes. The key advantages of Event Storming over Capability Modeling are:

  1. It adds Time as an underlying axes when describing the processes/workflows happening within the business; this exposes Context in a better way.
  2. It identifies the Capabilities and Relationships between them.
  3. It identifies the significant Domain Model belonging to the Capability.
  4. It identifies the Messages (and Commands) that are passed across the Capability boundary - thereby helping us easily conceptualise the outcome as a Modular Monolith or as a Distributed Application
  5. It helps us to embrace Domain-Driven Design with far less upfront ceremony.

We want to recognise that Capability Modelling has definite use cases and applicability. Event Storming does not replace this.

What Event Storming is not

  1. Event Storming is not Domain-Driven Design. While event storming is based on several DDD concepts — including bounded contexts and aggregates — DDD is more complex. Event storming focuses on an interactive collaborative whiteboard exercise that engages all domain experts. It is simpler and does not require extensive training as formal DDD does.
  2. Similarly, Event Storming is not Design Thinking. While both processes involve several workshops with multiple stakeholders doing business process mapping exercises and white boarding, they do differ. Event Storming focuses on the decomposition and categorisation that defines the bounded context (and microservices that belong to it). Design Thinking involves a phased process that includes problem definition, need finding and benchmarking, ideation, prototyping and testing. Technically, Event Storming focuses on the things that are currently happening in the business process, known as events, while Design Thinking revolves around empathy and pain points.

So, how does it work?

  1. Event Storming sessions are collaborative workshops among significant stakeholders.
  2. Usually, SMEs, product owners and development teams meet in a room and participate in the session (more on the process later).
  3. Logistically, the following supplies are necessary to facilitate such a session
    • A big wall (we put a paper roll on the wall, and stuck all sticky notes on it)
    • Lots of coloured sticky notes (these are not random colours; see the ‘Design’ section below for the standard colours)
    • Pens and paper
    • No chairs 😆 … it helped us to have everyone stay on their feet to encourage participation in the overall discussion
  4. Anyone who has a clear understanding of what happens within part/all of the system and can play a representative role should be invited to this meeting. We were clear in stating that this session is to discover the hidden nuances of the existing system and would expect a relaxed environment so that everyone can express their thoughts candidly with the team. We recognised that organisational politics may come into play and made it clear up front that this kind of behaviour would hinder communication and slow down our progress. We believe it worked 😊
  5. Finally, the session was typically a full day with intermediate breaks. We needed to have 3 sessions like this.

Learn how to take your digital solutions to market faster. Download the White Paper now!

Design Artefacts

During the Event Storming session we discover certain design components.  These are what make up the solution space. The idea is to discover these during the session and represent them with a sticky note of a specific colour.

  1. Commands (represented with blue coloured sticky notes):  These are instructions issued to the system so that it takes some action. The system reaches a new state after the action/operation has happened.  These can originate from a user or system or by another event. As an example Create New Loan Application is a command.
  2. Events (represented with orange coloured sticky notes):  These are something significant that happened within the system when a command has been processed. Typically a domain event causes the generation of new instances of the domain model or alteration of state for existing instances. As it is an Observed the Reported phenomenon (like ApplicationCreated, AccountWithdrawn and so on) - these are often represented in the past tense. Identification of Events is the key. Often Domain Experts and SMEs spearhead the discovery process of Events.
  3. Aggregate (represented as tan coloured sticky notes):  These are “things” that a group of events operate on or generate. Typically aggregates are higher-order business entities represented as nouns. As an example Loan Application is an Aggregate.
  4. System (represented as pink coloured sticky notes):  These represent systems involved in the domain. They may issue commands or receive commands along with triggering events. As an example, an external brokering solution which creates Loan Application inside the system, is a system. Systems in this context can be 3rd party services or an internal Self - Contained service that happens to interact with the application in question.
  5. User (represented as yellow coloured sticky notes):  These are human users involved in the process. They may be a single person or a department/team. Yellow sticky notes help show how complicated the workflow of a business process can be based on the number of departments involved and the amount of back and forth.
  6. Read Model (represented as green coloured sticky notes):  This represents data that may be critical for a user or system to make a decision. I have not seen this one used often, but it can be helpful when there needs to be an emphasis on what data the user sees.
  7. Policy (represented as grey coloured sticky notes):  These represent standards or rules that may need to be executed, such as rules for a compliance policy.

Sample Process - Loan Approval Process

Now that we have covered the foundations, let's apply Event Storming to a simplified loan approval process domain model taking inspiration from the following resource from the internet.

  1. Let’s assume that follows the steps below towards ultimately granting a loan to its customer, who aspires to buy luxury cars.
  2. Application - The customer approaches nodal authorities expressing their interest to apply a loan. They provide an initial set of collateral which will be used by
  3. Data Gathering - On the basis of the submitted application and collateral provided, the assessor assesses initial credibility of the applicant. S/he requests additional documentation if needed. In response, the customer or the nodal office submits additional information.
  4. Validation and Credit Evaluation - Some assessments are performed to validate customers credibility. At this stage, on successful completion of the validation and credit evaluation process, the loan request gets conditionally approved. Lenders typically evaluate factors like credit-worthiness, loan size, frequency of borrowing, length of commitment as part of the credit evaluation process.
  5. Risk Analysis - As the next step, further analysis is performed by a credit analyst to determine a borrower's ability to meet their debt obligations.
  6. Underwriting - Finally, the lender determines if lending the money would be within the acceptable risk levels. Underwriters are appointed who assess the borrower's ability to repay the loan, based on information produced in the prior steps.
  7. Closing - In closing, all relevant legalities are completed to finalise the disbursement of the loan to the customer.

Event Storming in Action

During the Event Storming process we perform the following steps in sequence:

  1. Identification of Domain Events
  2. Time Sequencing of Domain Events
  3. Identification of Triggers/Commands
  4. Identification of Aggregates and Emergence of Capability

Identification of Domain Events

In this very first step, stakeholders join a workshop to identify key domain events. This step is exploratory and the focus is on letting people brainstorm and share what they know openly to the team. The information originating out of this session will need to be pruned, refined and merged into a more meaningful format.

As an outcome, the following events were identified:

Identification of domain events

Time Sequencing of Domain Events

    1. In this step, the events are sequenced in ascending order of time. So events happening earlier appear before those happening later - laying out a time sequenced event process.
    2. Note, events that happen in parallel have been stacked up vertically. For instance, once the Underwriting is initialised, Credit, Capacity and Collateral are verified in parallel flows. Also, there are cases when an event (and subsequent events to it) - happens in a loop. The idea is not to put an algorithm at this design stage - it is more to discover what happens before and after - thus being able to discover the end to end flow.Time sequencing of domain events

Identification of Triggers/Commands

    1. Commands can be initiated by actors, both internal and external to the system. For example, when a new user submits a new loan application via broker, it results in issuance of Create New Loan Application Request command. Commands are always expressed in the present tense.
    2. Commands help in identifying broader context within the system in which it operates.

      Identification of triggers and commands.
    1. A Quick reminder regarding the colour codes:
      • Yellow represents the actors
      • Blue represents the commands issued by the actors
      • Orange are the events we started with
    1. The view identifies who issues the command that causes the event to occur.
    2. Note: For the sake of simplicity, a lot of the detail has been removed from the diagram, to focus on the key elements.

Identification of Aggregates and Emergence of Capability

    1. In this step, the Aggregates are identified. Commands cause Events. Events result in creation/updating of Aggregates. Aggregates are in a way outcomes that cause the process to progress further. Examples include a Loan Application, Supporting Document - represented as light yellow boxes in the diagram below.
    2. The ensemble of Command - Event & Aggregates are grouped into Capabilities - a logical partition of the system, within which an Aggregate sustains a unique meaning.Identification of aggregates and emergence of capability.
    3. As shown above, the team finally realised 3 separate capabilities.
    4. Note: The Loan Document aggregate appears in all three bounded contexts. Typically, the aggregate maps to one or more microservices.

Processing the Outcome

Once the high-level capabilities were identified the team used the information to form three separate modules within an overarching monolithic application. Eventually, it was identified that the key "Assess" module required different READ - WRITE characteristics than the other two. It was segregated into a separate microservice.  Given that we'd used the Event Storming technique and subsequently had clearly bounded context, the refactoring was pretty easy to implement.

Talk to an API expert

Lessons Learnt

We learnt several key lessons while conducting the Event Storming session.

  1. It is fast-paced:  The event storming approach reduces the time it takes to create a comprehensive command - event - aggregate (domain model). What used to take weeks can be accomplished in hours during a single workshop.
  2. It is straightforward:  Rather than using more complex approaches such as Domain-Driven Design, Event Storming breaks the process down into simple terms that both technical and non-technical stakeholders can easily understand.
  3. It is engaging:  One of the goals of Event storming is to make modelling fun. It is a hands-on approach to domain modelling that invites each person to participate and interact. Event Storming also results in more valuable insights as participants are more readily engaged in the process and happily offer their suggestions and expertise.
  4. It is effective:  Event Storming is not data modelling. Instead, it results in a fully behavioural model that can be quickly implemented and validated. For the best outcomes, teams should combine Event Storming with an implementation oriented toward domain-driven design.
  5. It helps in finding the right modularity:  While primarily used to design microservices-based solutions, the discovery findings can be equally applied in building modular monoliths.


Event storming is a powerful mechanism to understand and decompose a system into loosely coupled and highly cohesive services. One of the key benefits of the process is its ability to explain the system without going to a low level of code and functional detail.  We find Event Storming a really useful technique for business process discovery during Application Development projects.

Try Event Storming in your next project and write to us for further help, clarification and insight or just let us know how you got on!