Event Storming for Order Management System
In this article, I’m going to explain our event storming experience briefly.
As the Trendyol Order Management System team, we decided to re-platform our Order and Fulfillment services. Using Domain-Driven Design principles while doing so seemed perfect since we had already experienced DDD when we re-platformed Claim service.
“The heart of the software is its ability to solve domain-related problems for its user.”
-Eric Evans
Let’s start by explaining the basic concepts of DDD. Domain-Driven Design aims to create an environment where software meets the exact needs of the business domain. I can hear you say “Huh, it is already known!”. I know how it sounds but in the real world, it isn’t as easy as it sounds. We, developers, are filled with excitement to code when we start a new project. We start to code, and day by day our project gets bigger and more complex. When a problem occurs, a typical developer tries to solve it with new technology since it excites him/her to do. But in fact, most of the problems are caused by the lack of domain knowledge, not the technology. Eric Evans, who is the writer of the Domain-Driven Design-Tackling Complexity in the Heart of Software, claims that the problem is hidden somewhere in the domain and it should be solved by understanding the domain better.
To understand the Domain-Driven design better, you should know some terms like Ubiquitous Language, Bounded Context, Aggregate Roots, etc.
Ubiquitous Language is the common language spoken between Domain experts and developers who work in the same domain. DDD suggests that everybody who works in the same business domain should speak the same language. That language is our ubiquitous language and that domain where the language is meaningful is our bounded context. To be more clear we can simply look into real-life examples: In Italy(bounded context), everyone speaks Italian(ubiquitous language) and any Italian can be understood.
Unfortunately, I’m not going to explain each term and concept of Domain-Driven Design since it is not the subject of this article. But if you’re interested in learning more about DDD I recommend you to look at Domain-Driven Design Distilled, a book written by Vaughn Vernon.
What is Event Storming?
We decided on applying DDD, that’s good, we already have done it, we could do it again. But could we do it better? That was the question in our minds. Both Order and Fulfillment services were more complex than Claim service. There were newbies to the domain including me and we weren’t able to participate as needed when a decision about re-platforming was made. As a team, we wanted to ensure that each team member has nearly the same domain knowledge. We had to model our domain to understand it better. Even though there are a lot of modeling techniques, none of them was simple enough for domain experts to participate in the modeling phase. To create a ubiquitous language we need domain experts and domain experts need a better modeling technique. These main problems lead us to use a different domain modeling technique and Event storming was the answer.
EventStorming is a flexible workshop format for collaborative exploration of complex business domains.
-Alberto Brandolini
Event storming is a fun way to increase the knowledge of business domains. It requires the collaboration of everybody in the business.
The things you need for an event storming session
- Lots of different colored post-its or sticky notes or some paper to put on a wall.
- A marker, a big roll paper or a whiteboard or a wall.
- The development team, QAs, product managers or product owners, stakeholders, etc. Briefly, people who can ask the right questions and who can answer right must attend the session.
The most beautiful part of event storming is that it has more than one form. We used even storming to see our domains clearly, was it the only and perfect way of event storming? Of course, not. That’s why we did it twice. I will tell you both the first and the second sessions and I hope you will understand it is beneficial when exercised correctly.
First, we started the session by differing the post-its according to their colors. Although all colors for events, aggregates and commands have specific colors in event storming book, we didn’t want to spend time to find the right colors. We used dark pink for events, green for commands, yellow for aggregates in the first event storming sessions.
- Event: A message is sent asynchronous which is recognized by the software.
- Command: An action that causes the event to occur.
- Aggregate: Much like domain objects.
- Policy: A business rule that invokes a command to an event.
The event storming session started by writing events to post-its one by one. Since it was our first event storming session, everyone was feeling a little bit nervous but eventually, someone took the step and attached post-it to the wall. Then the team followed. The biggest challenge of our first event-storming session was name conventions and trying to catch the perfect design at a glance. Everybody was trying to write events according to their occurrences in the timeline. So it was hard to participate in the session for newbies. In the end, there was someone in front of the wall, he was writing events and attaching post-its to the wall while others telling which events should be written. Even writing the events took one and a half hours, and yet there were still some questions about the names of events and also their necessities. The session was tiring and confusing for all of us. We attached some alarming post-its to confusing parts and decided to wait until the next day. A day later, the team was ready to write commands. To understand where user interaction occurs in our domain, we attached post-it with a little man on it to the commands. The final step of our storming session was deciding the aggregates which related to which commands.
After the first event-storming session, we had a clue what event storming is. Yet we weren’t satisfied enough with the session and we want to try again. Before repeating the session, we wanted to clarify that everybody understood why we need an event storming session again and what our faults were in the previous session.
- The lack of participation.
- Focusing the whole domain at once.
- Trying to catch the perfect design at once.
- Not limiting the time to debate on something.
These mistakes kept away from the real domain problems in the previous session. We promised ourselves not to repeat these mistakes and decide to do another session.
The second session started by writing the events again. The rule was simple. Everybody could write any event in any order for the first ten minutes. In the beginning, each event was acceptable whether it is related to our domain, or not. It didn’t need to be written only once. Everybody can write the event even though it is already on the board. No one was allowed to remove an event from the board in the first ten minutes. The aim was to recognize the domain knowledge of ours without any interrupting.
After ten minutes, we ordered the events according to their occurrence in the timeline and removed the repeated events from the board. Some sticky notes with different names were pointing to the same events. In that situation, a sticky note with a more appropriate naming was chosen to represent that event and the other ones were removed from the board.
Since we already have the minor information about our domain from the previous session, we wanted to focus on the pivotal events. We divided the timeline to three-part. The first part was starting the pre-order creation process, the second was starting the order processes and the third one was starting the fulfillment process. The pivotal events were the event which is occurred in the timeline where the one part has ended but the other has just started. These pivotal events lead us to commands and policies. In what circumstances these events could occur? With policies, we could define our happy paths and opposites. When a different thought about some path came to mind, the team discussed it in a limited time. When we couldn’t agree on something, we put some pink sticky notes on it to decide about it afterward. That way we didn’t spend all of our energies on one thing.
In the end, the deeper problems of our domain got a little bit clear.
To sum up, In the first session, we had a different superficial outlook on our domain. We didn’t reach most of the problematic parts of the domain. In the second session, we asked different questions, thought the edgy scenarios and collaborate. Focusing on the deeper level of problems gave us a deeper outlook, hence it brought its solutions.
There were newbies in the team and with these sessions they could have a greater knowledge of the domain. So, we could say it was a pretty good orientation :) And for the last, we decided using design level event storming in groomings. I’m going to tell you how we applied design level event storming in another article.
I hope you enjoy the event storming as much as we did. Thanks for reading :)
PS: Don’t hesitate to contact our beloved HR team for tempting career opportunities.
