Event Storming — The Storm That Cleans Up The Mess!
When I was a member in social organizations (Enactus ENIT & CECLTMS) , Launching a project started with the famous brainstorming phase. Our team gathered in front of a white board and start exchanging ideas. We’ve done it through three sessions.
At the first session, we tried to detect problems. For example, if our project is going to be related to saving our environment then we look for issues faced in our daily life, write them down in post-its, stick it to the board and finally we classified them according to a specific criterion. The second session is about finding solutions, so we’ve tried to give each problem at least one solution. For sure, our team needs to make choices depending on our tools, our abilities and other external factors to ensure the feasibility of the project before launching it. It’s the matter of the third session where we turn into voting.
Draining ideas is done by asking three major questions What? Why? And How? — those who read my blogs know that I’m a big fan of the WWH detection method. Obviously, this is how I see myself being problem-solution oriented.
The brainstorming ends with a clear mind map which allows us to start planning for the next steps in building and implementing the project.
Why I’m bringing this experience here?
The reason is that, recently, a software engineer, I discovered Event Storming which is the way to launch an IT project.
An IT team gathers with domain experts and business analysts in front of a white board with some post-its and pens in hand to start distil the problem space by determining the business capabilities — What are the important features related to this business/domain?
Digging into solution space comes next. It’s about defining and aligning the bounded context (BC). Finally, they produce a context map which illustrates relationships between those BCs — Isn’t it quite similar to brainstorming? Well, I think so.
What is Event Storming?
It is a workshop-based method invented by Alberto Brandolini and used to gather domain business requirements in a collaborative way. It helps in finding out how things are supposed to happen in the software. It allows to focus on the business domain workflows and thereby to prepare for the implementation phase. It requires some simple tools: post-its, pens and a white board or if your team is working remotely then there are plenty of online whiteboards that can be used.
How to start the event storming?
- Extracting domain events:
Domain events are simply objects that define some sort of event that occurs in the domain that domain experts care about. [1]
As a first step, you’re not obliged to answer “When does it happen?” The goal is to answer in the past tense the question “What happened?” in order to discover the domain events.
Then, you can put your domain events on a chronological timeline from left to right.
In the case of an e-commerce project, your events can look like:
- Product added to cart
- Shipping details confirmed
- Total cost calculated
- Payment card submitted
- Order Confirmed
- Order Shipped
- Order Delivered
- etc..
2. Setting up Commands:
An operation that effects some change to the system (for example, setting a variable). An operation that intentionally creates a side effect. [2]
Focus on answering “Why does it happen?”. Command is the cause that generates a domain event. It is called by users or an external system.
Your commands may look like that in the case of an e-commerce project:
- Add product to cart
- Confirm shipping details
- Calculate total cost
- Submit payment card
- Confirm order
- Fulfill Order
- Receive delivery notification
- etc..
3. Find out Aggregates:
An “aggregate” is a cluster of associated objects that we treat as a unit for the purpose of data changes.” [2]
An aggregate is a collection of related value objects and entities that have a local responsibility and represent a specific business concept.
Try to define for each event/command the aggregate that they belong to.
4. Write your Policies:
An event that occurs triggers a policy that invokes a command. Try to answer the question “How does this happen?”
Policies are written in this format: WHEN event THEN command. For example, when the payment card is submitted, then confirm order.
5. Delimit Bounded Context:
The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently. [2]
At this step, try to draw boundaries that delimit each consistent context. Thereby, the context map is clear, and the relations and communication between contexts are determined.
In the case of building a modular monolith, BCs represent the subdomains. However, if it’s a distributed microservices then BCs help in defining the microservices.
In Summary,
How to use event storming to achieve domain driven design?
Domain Driven Design or DDD is nowadays becoming popular in the software development industry. It’s a modelling method that requires the decomposition of the problem domain to its sub-domains which will favor modularity of the system. It’s very helpful for implementing the microservices architecture and the event driven architecture. However, the concepts behind DDD are complex enough to use a modelling language such as UML to set up the system design. Also, UML requires some knowledge to be understood by clients or domain experts and it takes time to be established correctly. This kind of reasons has led Alberto Brandolini to use post-its and pens and to give birth to event storming as a quick method to understand the domain following a collaborative mindset. Event Storming is very used by DDD community because it’s based on its fundamental concepts (Domain events, commands, aggregates… ) as well as it guides developers in setting up the structure of the project and starting its implementation.
I’ve already written an article to talk more about DDD and how Eventstorming can help to apply the DDD patterns, you can find the link in the “Read Further” section below.
In the case of adapting hexagonal architecture,
The domain layer will be the holder of aggregates and value objects as well as an implementation of domain services and domain events. The domain layer exposes its ports (API & SPI) to adapters on the application and infrastructure layers.
The application layer contains the inbound adapters like REST controller which uses DTOs and commands as well as it injects the service exposed by API port to talk with domain layer.
The infrastructure layer contains the outbound adapters for a data store such as repository which implements the interface exposed by SPI port to handle CRUD.
What are my favorite tips to succeed in event storming workshops?
- A bounded context solves one problem and it can contain more than one aggregate.
- You can create two different aggregates solving one problem delimited by one bounded context.
- Be loyal to your ubiquitous language which is the common language and concepts between developers and domain experts used to discuss the software problem domain. Don’t use different vocabulary to refer the same concept.
- Event storming is a series of multiple sessions. At each session, try to refine your diagram.
- Event storming is a way for developers to earn solid knowledge about the problem domain before start coding.
- Be sure that your command/event are coming from a business need.
- Don’t be too much influenced by the CRUD approach while extracting your domain events.
- Setting up your user stories helps in the domain events’ discovery.
- Show empathy, be problem-solution oriented and welcome different points of view.
How did event storming change me?
I had always considered DDD as a way to modularize applications yet it’s not as easy as it sounds. However, the event storming makes it not easy but clear and organized. Modules boundaries are implemented wisely without being influenced by any technology or trend.
Event storming helps me to learn from a failed microservices architecture where I wasn’t sure about my BCs, the responsibility of each microservice and how they should communicate as well as the degree of coupling and cohesion between them.
Our event storming diagram is still on process, but I’m pretty sure that it will positively impact our code.
Turning back to my experience in the social life, I believed that brainstorming helps each member to become an innovator not simply an imitator. So, as usual, I leave you with this little piece of advice
“Event Storming helps you as a developer to become an innovator not simply a programmer.”
References:
[1] [https://khalilstemmler.com/articles/domain-driven-design-intro/]
[2] Domain-Driven Design by Eric Evans
Read Further:
