Event Storming, Black Magic or Real?
Prelude
I would like to know if there will ever be a silver bullet, a magic wand or a secret spell that can help us immediately see the business as is, including all its functions, policies, events and processes. Not the perception of what the company does but what it really does.
Or translate a business vision into a set of technical requirements that developers would truly understand.
Hence many projects need help getting off the ground or get cancelled mid-way.
I am skeptical that we can solve this problem. We are too emotional, too arrogant, too rigid and above all, extremely lazy to communicate or to upkeep our documentation matching the working technology. We are too protective of our silo, our domain. “Do not enter my domain, ye of little intelligence.”
AI will likely solve this problem eventually; the developers are no longer required; AI can write the code for us. All business people need to do is ask ChatGBT version 50 to build and deploy their desired software.
But wait,
even then, you need to explain to an AI like ChatGBT your essential ingredients, including your business events, policies, commands, and input data requirements for it to build your technology.
Alberto Brandolini is up to something. He came up with the idea of the event storming that claimed it would address those questions. I decided to give it a try. I had my doubts. The grey cloud I have seen hovering over every business I got involved in their tech, twenty years of seeing challenges in our industry.
The Article
Let’s jump right to it. I am not going to describe what Event Storming is, you can read the book Event Storming by yourself, but I want to give you a sneak peek of what blew my mind when I used it in a project.
Suppose your boss came to you and asked you to build a headless auction/bidding engine. He gives you a requirement that looks like this:
- Potential buyers should be able to place a bid on an item
- You don’t need to host the item data; there is another system for it
- Bids placed should be checked for validity; you must detect fraudulent bids.
- All incoming bids, valid or non-valid, should be stored for later use
- Bids are either going to be accepted or rejected
- If a bid is accepted, we will declare the buyer winner, and all others outbid.
- We notify everyone of the change of item state.
Simple enough? Not for the developers. But let’s make it simple.
Involved People
It would be best if you appreciated that event storming is impossible in the confidence of your home office and away from the business people.
Here are the people involved in the event storming practice:
- Solution Architechs
- Enterprise Architects
- Business Drivers
- Subject Matter Experts
- Experts from each silo in the company
Identifying Events
We first want to extract all the domain events produced due to the execution of internal logic. For example, when a person places a bid, we would know the event “Bid is placed” occurred. This passive voice of an event is very natural to business people. Business communication is something like “When a bid is placed, check for fraudulent activity.”
Let’s show the events with orange stickers. We must adhere to the sticky colour rules.
Let’s put only some sticky notes related to the abovementioned requirements.
Wait a second; if you are a developer or solution architect, you can see something interesting emerging. If you are a business person, you can see events you can discuss and drill down further.
Identifying Commands
Let’s build some symmetry. We know users coming online to bid on something don’t give a damn about the events. They issue a command. “Place Bid.” We can then pair them with our events produced.
We identify commands using blue stickers.
Now developers and solutions architects smile a bit, and business people have a second language to communicate with arrogant techies. Body postures are changing.
Systems
We all know that commands are not given to angels, and events are not produced in the heavens. What connects events to commands are systems.
And systems are captured by pink sticky notes.
So let’s put the systems in our sticky notes.
At this point, business people can see what systems will be used and where without being technical. Technical people can see their design and development path slowly emerging.
Actors
Next, we want to know who decides to issue commands. We want to identify the actors. Actors are always motivated by the real world. For example, a buyer needs a bulldozer and is placing a bid on a bulldozer.
Sometimes actors trigger a chain of events. Let’s go back to our sticky notes and place actors on the map.
However, the actor has to pass his/her offer. That becomes input data.
Input Data
The next step is to identify and describe what data is incoming and what is produced.
Let’s place the read model in our sticky notes. Keep in mind that events can result in one or many read models.
This, to me, is very exciting since both technical and business people can read this and explain it to you meaningfully.
You don’t see UML or BPMN diagrams; you don’t even see the flowchart diagram. Everything is fuzzy and clear at the same time.
However, some of these commands are executed as a result of policies business people put forward. They are not necessarily a chain of command but policies.
Policies
Business people understand a lot of activities in business as policies. Business and technical people can agree and describe policies such as return, data retention, notification policies and data security policies.
Policies can issue or trigger several commands. Let’s now change our stickies to reflect the policies. And by the way, the policy sticky colour is dark purple.
This is the moment you can see what you have missed, your opportunities and potential errors in the flow.
Have you noticed you can read this from left to right, and everything is almost captured?
Have you noticed that both business and technical people speak the same language and can communicate without tension?
Hot Spot and Opportunities
In any business, there are always questions to be answered and opportunities to turn into financial gain. When we lay our domain events, systems and commands, without a doubt, people involved would come across many opportunities for improvements and stumble upon some uncertainties. We represent them with hot spot red sticky and dark green opportunity sticky.
The following diagram shows a hotspot identified near “bid rejected.” there are two possibilities:
- Either you don’t have anything else to do after the rejection
- Or have we missed another set of commands, events, and input values
The answer to any of those two scenarios would clarify things further for the people involved and advance the business cause.
Next,
You can also see the dark green sticky near the fraud detection. Some people suggested we turn the fraud detection process into a service or product. This could become another source of revenue.
Interestingly, if you are a DDD practitioner, you can start identifying your entities, value objects and aggregates. As you can see, we placed Item aggregate near “bid placed” events. But how?
Aggregates
Let’s identify all of our aggregates related to the stickies above. Now we are entering the software design part of the event storming. This is where most of the business people get out of the room and leave the board for the kids to play, the solutions architects and developers.
Let’s first set the ground rules. Blue stickies are entities, green stickies are value objects, and orange are aggregate rutes. We group stickies to create an aggregate.
There are many aggregates we can identify from our event storming stickies but let’s focus on a select few known entities:
As you can notice, the above stickies have no colour simply because we have yet to decide on the grouping and type. Let’s do that now.
Let’s explore; we know an item can have multiple buyers, multiple bids and is always associated with a supplier. We know a bid is associated with a buyer, supplier and an offered price. We know a buyer can win and buy multiple items and has placed multi bids. We know a supplier has multiple items.
One of the DDD rules is that we access the aggregate from the aggregate root, so let’s define our aggregate roots.
The next question we ask is can each aggregate group live independently? Do they make sense to exist independently? We realize that a Bid without an Item doesn’t mean anything. So let’s change bigs to an entity. The new grouping looks like
Another DDD rule is one aggregate is also a transactional boundary. Do we want to change supplier and buyer when a new bid comes into the item? No. So let’s introduce some value objects.
What’s essential for us to is the Item. We have identified that we can reference other aggregates by their ids (value objects). Let’s remember about other aggregates for now and focus only on the Item since we need to update buyers and suppliers as part of the bidding process.
As you can see, the above aggregate is an excellent fit for our commands and domain events.
Now developers can understand the aggregate and start planning the development roadmap with the product owner and scrum master. This level of detail will be available to the business people.
Now let’s go back to the other diagram where we had opportunity, hot spot and aggregate and it should now make sense.
Value Stickers
As you learn your system through coloured stickies, you see a few more things than commands, events, systems and actors. We discussed the hot spot and opportunity. However, you also can see values in certain areas. Values are not necessarily positive; they could be neutral or negative.
Values then come in two colours to indicate the type, super dark green for positive and super dark purple for negative.
You can see two values added to the following image, one that says there are a lot of values in the rejection of fraudulent bids and one that says the winning calculation process is complex.
Let us decide
Now we get to a place where we are comfortable with everything out and about. Let’s discuss what needs to be addressed to go from where we are to where we want to be. We ask everyone to vote on what we need to address immediately. It is time to bring in the blue sticky with an arrow.
As you can see, everyone decided to go with understanding what happens after the bid is rejected.
Conclusion
The process has always been time sensitive. It starts somewhere and ends at another time in future. So let’s add the timeline to it and wrap it up.
You can drive other types of diagrams from the event storming. Keep in mind that we didn’t dive deep into the event storming. This article was to show the values it brings. There is a lot more to event storming that I covered in this article.
I encourage you to give event storming a try if you are
- Startup
- An organization with multiple silos
- An organization that has gone through one or various acquisitions
- An organization that faces challenges with business or technology
- A new solution architect at a company and try to understand everything that the business does in a short time
Create a bridge between business and technology using event storming. Thanks, Alberto Brandolini, for your beautiful contribution.
This article was a quick practice to show event storming, and there is a lot to improve, especially around the sticky notes. I welcome your feedback and corrections. I also have to say special thanks to Amichai Mantinband for his amazing Figma stickies.
Amendments
Please also watch this video I created on Event Storming
Please read this article by George. He has covered a few points that I have missed in my writing. Especially about the concept of the “Deep Model.”
