07 How to initiate Event Storming sessions in the context of online food ordering scenarios #
The most critical challenge in microservice design is the decomposition of microservices. If the decomposition is unreasonable, it not only fails to improve development efficiency but also lowers it. Therefore, it is important to pay attention to the design of “small and specialized” microservices. “Small and specialized” means that the design of microservices requires higher requirements, including “low coupling and high cohesion”. So how do we achieve “low coupling and high cohesion” and realize the “small and specialized” microservices? This requires the use of “domain-driven design” as a methodology to guide our development.
The use of “domain-driven design” is a widely recognized solution in the industry for how to decompose microservices and achieve high cohesion and single responsibility of microservices. But how should domain-driven design be conducted? How do we use the correct approach to design microservices step by step from requirement analysis to software design? Let’s practice the design process of microservices using an online ordering system as an example.
Online Ordering System Project #
We are all familiar with online ordering systems such as Meituan, Dianping, and Baidu Takeout. The specific business process is as follows:
Business process of online ordering system
- When we enter the online ordering system, we first see different restaurants, and we can see their menus when entering each restaurant.
- When placing an order, the order will include the restaurant, dishes, quantity, and delivery address.
- After placing an order, the corresponding restaurant will receive the order.
- Then, the restaurant accepts the order and starts preparing the food.
- When the food is ready, the delivery person will be notified for delivery.
- Finally, when the food is delivered by the delivery person, the order is completed and we receive the delicious food we ordered.
Now, we want to design and develop an online ordering system based on microservice architecture. So how should we start from analyzing and understanding the requirements, and step by step apply the domain-driven design approach to finally decompose the system into microservices?
Ubiquitous Language Modeling #
The greatest risk in software development is requirement analysis, because during this process, no one can clearly explain the requirements.
Lack of understanding between development and clients #
During this process, clients:
- Have a clear understanding of their domain knowledge and the business pain points they urgently need to solve.
- However, they do not know how technology can solve their business pain points.
So when clients propose requirements, they are using their limited knowledge to imagine how technology can solve their business pain points. Therefore, the business requirements they propose are often not feasible, either because they are technically difficult to implement or because they are not the optimal solution.
At the same time, during requirement analysis, developers:
- Have a deep understanding of technology and the business problems it can solve, and understand how it can be done.
- However, they lack knowledge of the client’s specific business domain, making it difficult to accurately understand the client’s business pain points.
This limits our design and results in a system that cannot perfectly solve the user pain points.
Therefore, during requirement analysis, neither the client nor us can have all the knowledge required for accurate understanding of the requirements. This leads to a situation where neither the client nor us can accurately understand and describe software requirements. In requirement analysis, it is often the case that the client thinks they have described the requirements clearly, and we think we have understood them. But when the software is developed, the client realizes that it is not the software they need, and we also realize that we did not truly understand the requirements. Nevertheless, the client still hasn’t figured out what they want, and we don’t know what to do. This is the tragedy of software development.
How to overcome the challenges of requirement analysis? #
How can we break through this impasse? The key idea lies in “ubiquitous language modeling”. This means that the root cause of the above problems lies in the “communication barrier” caused by language, which prevents us from understanding each other. Therefore, the solution is:
- I actively learn your language, understand your domain knowledge and communicate with you using your language.
- At the same time, I also actively let you understand my language, understand my domain knowledge, and communicate with you using my language.
Returning to the field of requirement analysis, we clearly understand technology, but not the business. Therefore, we should actively seek to understand the business. So how can we understand the business? Should we read books and study the business slowly? Not necessarily, because our goal is not to become experts in the business domain, but to “master the business domain knowledge relevant to software development”. Learning aimlessly in the business domain has low efficiency and limited results.
Therefore, we should learn from the clients, for example, by asking them questions and carefully listening to their description of the business, and quickly learning about the business through discussions with them. However, a very important key during this process is to “pay attention to the specialized terminology used by the client when describing the business process, and make an effort to use this specialized terminology to discuss the business with the client.” Over time, as you communicate with customers in their own language, your communication will become smoother and customers will perceive you as more professional. They will be more willing to communicate with you and discuss deeper knowledge in the business field. As your understanding of the business deepens, you will be able to accurately understand customers’ business and pain points, and use your technical expertise to solve their pain points with more reasonable technology. As a result, your software will become more professional, and customers will increasingly enjoy purchasing and using your software, leading to long-term cooperation.
Example of my project application #
Using a remote intelligent diagnosis and treatment data model I have worked on as an example, this is a data model targeting traditional Chinese medicine (TCM). In the process of discussing requirements with the customer, we quickly discovered that many terms used by users in describing the diagnosis and treatment process of TCM are significantly different from Western medicine.
For example, when describing patients’ symptoms, they usually don’t use the term “symptoms” but instead use “manifestations”. Manifestations include symptoms, signs, and test indicators, which are all external manifestations of the patient’s condition captured by the doctor in different ways. Furthermore, they don’t use the term “disease” for diagnosis, but use “pattern”. In TCM, patterns are considered the internal root causes of a patient’s disease. By understanding and addressing patterns, the disease is naturally cured. Once we understood these terms, communication became exceptionally smooth when discussing with the domain experts using these terms. The customer felt that we were very professional, understood them well, and became very proactive in discussing requirements. This quickly established a long-term cooperative relationship.
At the same time, during this process, we can involve the customer in our analysis and design work by using language that they can understand to explain how we design software. When customers feel involved, they will have a stronger sense of recognition for our software, which is beneficial for software promotion. Additionally, with their participation and understanding of our software development process, a mutual understanding is gradually established. This helps to ensure that the requirements they raise in the future are more practical and avoids requests that cannot be implemented, resulting in a significant improvement in the quality of requirements.
Event Storming Workshop #
What is Event Storming? #
During the initial requirements analysis phase in domain-driven design, the basic approach to requirements analysis is to unify the language, which serves as our guiding principle. At the operational level, the practice method that can be used is called “Event Storming”. It is a DDD (domain-driven design) practice method based on workshops that helps us quickly discover events happening in the business domain, guiding domain modeling and program development. It was invented by an Italian named Alberto Brandolini and is widely used in business process modeling and requirements engineering.
The basic idea of this method is to gather software developers and domain experts together to discuss and learn from each other, which promotes unified language modeling. However, its working method is similar to brainstorming, making the modeling process more interesting and making learning about the business domain easier. Therefore, the “storm” in Event Storming refers to using brainstorming meetings for domain analysis and modeling.
Now, what does “event” mean in this context? “Event as Fact” means that events that have occurred in the business domain are facts. Once an event has occurred, it becomes a fact and does not change. Therefore, an information management system can store these facts in the form of information in a database. Simply put, the function of an information management system is to store these facts, manage and track them, and improve work efficiency. Therefore, analyzing the business requirements of an information management system accurately means capturing the key facts that need to be stored during the business process, and analyzing and designing around these facts. This is the essence of “Event Storming”.
Conducting an Event Storming Workshop #
Therefore, practicing the “Event Storming” method means having developers and domain experts sit together and hold an event storming workshop. The purpose of the meeting is to conduct domain modeling with the domain experts, and the preparation before the meeting is to set up a large whiteboard and various colored sticky notes as shown in the figure below:
(Event Storming Workshop Image)
Once the Event Storming workshop starts, it usually consists of several steps. First of all, under the guidance of the product manager, we begin to clarify the domain events in the current business, which are the facts that have already occurred and need to be stored. At this point, we should follow the business process to comb through the domain events in order. For example, in this case, the entire process of online ordering can be divided into several domain events: “Order placed”, “Order accepted”, “Order ready”, “Order dispatched”, and “Order delivered”. Note that domain events are factual events that have already occurred, so they should be named in the past tense.
Here is an interesting question worth discussing. Before placing an order, users first select their meal. Is “User selects meal” a domain event? Note that domain events are important facts that have already occurred and need to be saved. In this case, “User selects meal” is only a query operation and does not need to be saved in the database, so it cannot be considered a domain event. So, are these query functions not included in the requirements analysis process?
Note that DDD has its own scope of application, and it is often applied in business scenarios involving create, update, and delete operations, while analysis of query scenarios is often not done using DDD, but through other methods. After clarifying the domain events, use orange sticky notes to list all the domain events on a whiteboard to ensure that all events in the domain have been covered.
Next, for each domain event, project team members begin to analyze the business around it continuously, adding various commands and events, and then thinking about the resources, external systems, and time related to it. For example, in this case, the “Order placed” event is analyzed first, analyzing the commands triggered by it, the people and things related to it, and the time it occurs. Use blue sticky notes for commands, yellow sticky notes for people and things, as shown in the following figure:
Analysis diagram of the “Order placed” domain event
The command triggered by the “Order placed” event is “Place order”, the executor is the “User” (represented by a stick figure), and the execution time is the “Order time”. People and things related to it are the “Restaurant” and “Order”. Based on this, further analysis can link the user to the user’s address, the restaurant to the menu, and the order to the item details.
Next, we need to identify the aggregates that may be involved in the model, as well as their aggregate roots. As mentioned in Lesson 5, an “aggregate” refers to the relationship between the whole and its parts. For example, whether a restaurant and a menu have an aggregate relationship depends on how their data is organized. If the menu is designed to be independent of the restaurant, such as “Kung Pao Chicken” being a menu item that is independent of any restaurant, and each restaurant is just referencing this record, then the menu and the restaurant do not have an aggregate relationship. Even if this restaurant is deleted, the menu item would still exist.
However, if the menu is designed so that each restaurant has its own separate menu, such as both restaurant A and B having their own separate records for “Kung Pao Chicken”, then the menu is considered to be a part of the restaurant. Deleting a restaurant would directly delete all its menus, so the menu and the restaurant have an aggregate relationship. In this case, the one representing the “whole” is the aggregate root, and all client programs must access various parts of the whole through the aggregate root.
Based on the above analysis, we believe that there are aggregate relationships between the user and the address, the restaurant and the menu, and the order and the item details. If there is an aggregate relationship, attach a purple sticky note to that relationship.
Following the above steps, analyze each domain event one by one:
Domain event analysis diagram for the online ordering system
After analyzing all the domain events, the next step is to divide the entire system into modules from a global perspective, forming multiple bounded contexts, and defining their interfaces and planning the context map between them.
Summary #
When designing microservices based on the principles of DDD, we start with requirements analysis. However, DDD completely changes the way we perform requirements analysis, by using a unified language model to help us proactively understand the business and discuss requirements with customers using their own language. The unified language model is the guiding principle, and the event storming meeting is the practical method. By using the event storming meeting to discuss requirements and build models with customers, we can gain a deeper understanding of the requirements and involve the customer more in the process. In addition, the event storming meeting can be part of the preparation for the iterative planning meeting in agile development.
However, how should the domain model formed through the event storming meeting be implemented in the design of microservices? What design and technical challenges will arise? The next lesson will further explain the implementation of domain models in microservice design.