Event Storming

• Event storming is a workshop-based technique to model microservices, invented by Alberto Brandolini in the context of domain driven design (DDD).
• It is easy and light-weight technique as compared to traditionally way of identifying bounded contexts and domain models.
• Event storming provides a way to ensure that sequence of events along with the application state which happens during the lifetime of the application has been well understood and scoped by the team.

Why and when to use Event Storming?

1. When organization wants to refactor monolithic system into microservices.
2. It provides the easy and light-weight technique to identify the scope of microservices by understanding the monolithic system.
3. It is very useful when existing services under monolithic system can have multiple functionalities.
4. Requirements not fully understood by the team.
5. Using event storming, team understand the complete domain.
6. When system is complex and difficult to understand.
7. Event storming session provides the high-level view of the domain and based on incremental design.
8. Using event storming, features and user stories can be easily identified.

Points to be considered during Event Storming:

1. Don’t use technical language.
2. Focus should be on domain
3. Team size should not be large
4. Include both domain & technical experts.
5. Use virtual whiteboard as it provides great flexibilities to manage sticky notes and relationships between them
6. Use different color sticky notes and display them under legends.

7. Plot domain events
   • Use orange color sticky notes
   • Use past tense verb
   • Use domain language and not technical language.
   • Discuss the order of event and place them in application timeline so that the sequence of events is clear to all.
   • Stack parallel domain events
   • Also plot events triggered by time, not triggered by user or system.
8. Plot definitions
   • Which can lead to different meaning
   • Use pale green sticky
9. Plot concerns
   • Use purple/red sticky notes
   • Plot all risks, issues and concerns
   • Plot blocker as well.
10. Plot commands
    • Use blue sticky notes for command and yellow sticky notes for user role/system with command sticky notes
    • Action or decision taken by user or system
    • Place them before the event.
    • Show use role(s)/system(s) which triggers the command along with the commands, this will help the team to understand the complete domain. Use yellow sticky notes for user/system.
11. Plot external or internal system
    • Use Pink color sticky notes
    • External system can emit events and receive commands
    • Place in-between command and event sticky notes
12. Plot policies
    • Use light purple or blue color
    • Policies are reaction of the events
    • Identified and plot reactive logic to an event
    • Place policy after event
13. Plot read models
    • Use pale green color.
    • Data or screen required to carry out the commands
    • These are the key data and not necessarily entities
      • Data on screen
      • Data from database
      • Specific part of UI.
14. Plot Aggregates
    • Aggregates are data holders on which commands act and emits events in response
    • Use pale yellow sticky notes
    • Paired with commands and events
15. Draw boundaries
    • Virtual whiteboard comes handy especially at the time of drawing the boundaries.
    • Group related aggregates, concepts, and commands
    • Don’t worry about the timeline as its not required now.
    • Refine boundaries by considering performance and transaction consistency between bound contexts.

Please share this