12 Domain Modeling - How to Use Event Storming to Construct Domain Models #

Hello, I’m Ou Chuangxin.

Do you remember in [Lesson 01] when I mentioned why we should choose DDD for microservice design? One very important reason is that the domain models established using DDD can clearly define the logical and physical boundaries of microservices. It can be said that in the practice of DDD, good domain models directly affect the design level of microservices. Therefore, I believe that strategic design in DDD is more important than tactical design. That’s the reason why our content will focus more on strategic design.

So what method should we use to analyze and build domain models from complex business domains?

It is the event storming that I have mentioned multiple times before. Event storming is a team activity where domain experts and project teams brainstorm and list out all the domain events in the domain. These events are then integrated into a final set of domain events. For each event, the commands that lead to that event are annotated, and the roles of the command initiators are identified. The commands can be initiated by users, third-party system calls, timers, etc. Finally, the events are classified and organized into entities, aggregates, aggregate roots, and bounded contexts. Event storming is a commonly used method in DDD strategic design, as it allows quick analysis and decomposition of complex business domains to complete domain modeling.

So how do we actually do event storming? What preparations are needed for event storming? And how do we use event storming to build domain models? Today, we will focus on addressing these questions and understanding the entire process of event storming.

What do you need to prepare for an Event Storming? #

1. Participants in the Event Storming #

Event Storming takes the form of a workshop, bringing together project teams and domain experts to gradually design a domain model through visual and highly interactive methods. Domain experts are essential core participants in an Event Storming session. Many companies may not have this role, so what kind of people should we look for to act as domain experts?

Domain experts are subject matter experts who have deep insights into the business or problem domain. They have a thorough understanding of how the business and system are done and also have a profound understanding of why the design is done in a certain way. If your company does not have this role, it’s okay. You can choose suitable candidates from business personnel, requirements analysts, product managers, or developers with years of experience in the domain based on this standard.

In addition to domain experts, other participants in the Event Storming session can include DDD experts, architects, product managers, project managers, developers, and testers, among other project team members.

Domain modeling is a process of creating a unified team language, so project teams should participate in domain modeling as early as possible in order to efficiently establish a common language for the team. When it comes to microservices development, the domain model is also easier to align with the system architecture.

2. Materials needed for Event Storming #

Participants in an Event Storming session write their ideas and opinions on sticky notes and stick them in suitable positions on the wall. This process is jokingly referred to as “wall-scribing.” Therefore, sticky notes and markers are essential materials. In addition, you can prepare some tape or magnets so that the sticky notes can be easily moved.

It is worth noting that during this process, we should use different colored sticky notes to differentiate domain behaviors. For example, we can use blue to represent commands, green to represent entities, orange to represent domain events, and yellow to represent supplementary information. Supplementary information is mainly used to explain important details, such as external dependencies. The colors are not fixed; this is just my personal habit. The key is to maintain consistency within the team.

3. Venue for Event Storming #

What kind of venue is suitable for Event Storming? Do you need to prepare a meeting room, projector, and chairs like a regular meeting? None of these are necessary! All you need is a long enough wall and a big enough space. The wall is used for sticking sticky notes, and the spacious environment allows people to move around easily, facilitating collaboration. Removing tables and chairs during an Event Storming session will increase the efficiency of the participants.

The inventor of Event Storming once recommended preparing an eight-meter-long wall to remove any spatial limitations. However, this is not a necessary condition. It depends on individual realities. The main point is not to constrain our thinking.

4. Focus of Event Storming analysis #

During the process of domain modeling, we need to pay special attention to the language and behavior of the business domain. For example, we analyze whether certain business activities or behaviors (events) will trigger the next business activity, and what inputs and outputs are associated with these activities (events). We consider who (entities) initiated the activities (commands) that triggered these events, and so on. By analyzing these hidden vocabulary, we can identify domain objects such as events, commands, and entities in the domain model.

How to build a domain model using Event Storming? #

The process of domain modeling mainly includes product vision, business scenario analysis, domain modeling, and microservice decomposition and design. Below, I will use the User Center as an example to explain how to build a domain model using Event Storming.

1. Product Vision #

The main purpose of the product vision is to design the top-level value of the product, aligning information about the target users, core value, unique selling points, etc., to avoid deviating from the product’s direction.

Roles involved in the product vision: domain experts, business stakeholders, product managers, project managers, and development managers.

Before modeling, the project team needs to consider the following two points:

1. What can the User Center do?
2. What are its business scope, target users, core value, and vision, and what are the differences and advantages compared to other similar products?

This process is also the process of clarifying the direction of User Center construction and aligning team thinking. Participants should express their opinions on each point (the content in the leftmost column of the diagram below) and write them on sticky notes, which are then placed on the yellow sticky notes. This process allows participants to fully express their opinions, and in the end, the divergent opinions will be united into a common language and establish the product vision wall shown below. If your team’s product vision and goals are already clear, you can skip this step.

2. Business Scenario Analysis #

Scenario analysis starts from the user’s perspective and explores typical scenarios in the domain by using use case and scenario analysis based on business processes or user journeys. The goal is to identify domain events, entities, and commands as domain objects that support domain modeling. Participants in the event storming should try to explore all the business details, express their opinions fully, and not overlook any important business points.

Roles involved in scenario analysis: domain experts, product managers, business analysts, architects, project managers, development managers, and test managers.

The User Center has the following three typical business scenarios:

1. System and position setup, which involves setting the menu permissions for positions in the system.
2. User authorization configuration, which involves creating user accounts and passwords and setting user positions.
3. User login and authorization verification, which involves generating user login and operation logs.

We can search for key domain events in the user’s business process step by step. For example, events such as “position created” and “user created” can be found. Then, we can determine what actions trigger these domain events, which may be one or several commands combined. For example, when creating a user, the first command is to retrieve user information from the company’s HR system, and the second command is to create the user in the User Center based on the HR employee information. After creating the user, the domain event “user created” will be generated. Of course, this domain event may trigger the next operation, such as sending a notification to the user that the user has been created. However, it may also end at this point. You need to analyze whether there are any further operations based on the specific situation. When analyzing scenarios, there will be many commands and domain events generated. I use blue to represent commands, orange to represent domain events, and yellow to represent supplementary information, such as an explanation that user information data comes from the HR system.

3. Domain Modeling #

During domain modeling, we will identify the relationships between the domain objects generated during the scenario analysis process, such as commands and events. We will identify the entities that generate commands and analyze the dependency relationships between entities to form aggregates, define bounded contexts for aggregates, and establish domain models and their dependencies. The domain model can guide microservice design from the bounded context upwards and guide the design of aggregate roots, entities, and value objects downwards.

The roles involved in domain modeling include domain experts, product managers, requirements analysts, architects, project managers, development managers, and test managers.

The process can be divided into three steps.

Step 1: Extract the entities that generate these behaviors from the commands and events. Use green stickers to represent entities. By analyzing the behavior data of the user center such as commands and events, seven entities that generate these behaviors are extracted: users, accounts, authentication tokens, systems, menus, positions, and user logs.

Step 2: Based on the management nature of the aggregate roots, identify the aggregate roots from the seven entities. For example, the user manages user-related entities and value objects, and the system manages menu-related entities, etc. Therefore, we can identify the user and system as aggregate roots. Then, according to the principles of business dependency and business cohesion, combine the aggregate roots with their associated entities and value objects to form aggregates. For example, the system and menu entities can be combined into the “system functionality” aggregate. Following this method, the user center has six aggregates: system functionality, position, user information, user log, account, and authentication token.

Step 3: Define bounded contexts and classify aggregates according to their semantic context. Based on the semantic context of the user domain, the user basic information and user log information aggregates together form the user information domain, managing user basic information, user login, and operation logs respectively. The authentication token and account aggregates together form the authentication domain, implementing different login and authentication methods. The system functionality and position aggregates together form the permission domain, implementing system and menu management as well as system position configuration. Based on business boundaries, we can divide the user center into three bounded contexts: user information, authentication, and permission.

Here, we have completed the construction of the user center domain model. Due to the large number of domain objects generated during the domain modeling process, we can use a table to record them.

4. Microservice Decomposition and Design #

As we mentioned in the basics section, in principle, one domain model can be designed as one microservice. However, since the domain modeling only considers business factors and does not take into account non-business factors such as technology, team, and runtime environment when implementing microservices, the domain model can only be an important reference for microservice decomposition, not the sole criterion.

Microservice design also needs to consider service granularity, layering, boundary definition, dependency relationships, and integration relationships. In addition to considering business responsibility singularity, we also need to consider the separation of transient and stable business, non-functional requirements (such as scalability, security, etc.), team organization and communication efficiency, package size, and technology heterogeneity, which are non-business factors.

The roles involved in microservice design include domain experts, product managers, requirements analysts, architects, project managers, development managers, and test managers.

If we do not consider non-business factors in the design of the user center microservices, we can design them as three microservices based on the one-to-one relationship between the domain model and microservices: user, authentication, and permission. However, if the user log data is enormous and requires big data technology to implement, there will be a technological heterogeneity between the user information aggregate and the user log aggregate. Although we placed them in the same domain model during domain modeling, if we consider technological heterogeneity, these two aggregates are not suitable to be placed in the same microservice. We can split the user basic information management and user log management into two microservices with technological heterogeneity, and implement them using different technologies.

Summary #

Today we discussed the design method of Event Storming and how to use it to build domain models. Event Storming is a method different from traditional requirements analysis and system design. The best way to learn is to practice it several times with different business scenarios.

Based on my experience, for a medium-sized project, the time required for domain modeling is usually around two weeks, which is similar to the time needed for traditional requirements analysis and system design. However, if all team members participate in the domain modeling process and establish a common language before project development, it will be very helpful for subsequent microservices design and development, and the time cost may also be reduced depending on the situation.

In fact, I also realized that many developers who are learning DDD for the first time don’t seem to care much about domain modeling, but only want to learn about DDD’s tactical design ideas and quickly get started with developing microservices. I think this is a misunderstanding of DDD. It deviates from the core design concept of DDD, which is to have a clearly defined domain model before designing clear boundaries for microservices. These two stages are prerequisites and we cannot ignore them.