DDD practice (1) – event storm landing process

Time:2021-11-27

Event storm is a team activity. Domain experts and project team members list all domain events in the field in the form of brainstorming. At this time, we get a collection of domain events, mark the command leading to the event for each event, and then mark the role of the initiator of the command for each event. The command can be initiated by the user, called by a third-party system or triggered by a timer. Finally, classify the events, sort out the entity, aggregation, aggregation root and bound context, and build the domain model within the bound context boundary.

1、 Preparation:

  • Participants: domain experts (business personnel, requirements analysts), architects, product managers, project managers, developers, testers, etc.
  • Preparation materials: stickers (at least 3 different colors), pen, tape or magnetic buckle.
  • Venue: a large enough wall and a large enough space, such as a large conference room.,
  • Focus: business action or behavior, whether action a will trigger action B, and who sent the action.

2、 Identify domain events

At the beginning of the event storm, domain experts and team members gathered in the large conference room to prepare stickers and pens. Everyone pasted domain events (business behaviors) on the wall through brainstorming. For example, taking e-commerce as an example, we got the following domain event sets:

DDD practice (1) - event storm landing process

image.png

Note that our expression is as follows: subject + attribute, such as “order has been created”.

This leads to another important concept in DDD – domain event.
Domain events are real business events concerned by domain experts. These events will have an important impact on the system. Without these events, the whole business logic and system implementation cannot be established. We can trace the past events through domain events, because the information meaningful to the business in the past will be preserved in some form. Domain events can be implemented as special event classes in the process of technical implementation, which is convenient to realize event driven design. Common impacts are:

  1. Some data is generated internally, which triggers some process or event state to change;
  2. Some messages are sent externally;
  3. Policy is the abstraction of branch conditions or complex business rules. The purpose is to focus on main business processes by reducing branch complexity. In the future, it may be some branch conditions or appropriate design patterns.

Scenario analysis: from the perspective of user operation, according to business processes or user processes, use case and scenario analysis methods are used to explore typical scenarios in the field, find domain objects such as domain events, entities and commands, and support domain modeling.

For example, a very important participant in the e-commerce business is the C-end user. In the e-commerce business, the C-end user will place an order, pay, receive goods, apply for a refund, etc., so we can search the key field events in the user’s business operation process step by step according to the business process. Participants in the event storm should traverse all business details as much as possible and give full comments. Do not miss business points. We write the identified domain events on stickers and stick them on the wall. For example, in this example, we use orange to mark domain events.

3、 Recognition command

In the second step, we identified some domain events. Who triggered these events? What is the trigger action? This is what we will do next: identify commands.

Commands can be understood as the operations of users in different roles on the interface, such as “add commodity”, “Edit inventory”, “submit order”, etc; Some commands may produce multiple events, which can be linked by arrows; In this process, we also need to mark the role with different colors. For example, in this example, we use blue to identify the command and yellow to identify the role.

DDD practice (1) - event storm landing process

image.png

4、 Extract domain objects

The business objects that generate these business behaviors, namely entities, are extracted from commands and domain events. A simple way is to extract nouns from domain events, such as “commodity” in “commodity created”, “order” in “order created” and “inventory” in “inventory locked”. We continue to use yellow stickers to identify these entities.

DDD practice (1) - event storm landing process

image.png

Entity: in the domain model of DDD, there are such objects that have unique identifiers, and their identifiers can remain consistent after various state changes. For these objects, what is important is not attributes, but their continuity and identification. The continuity and identification of these objects will span or even exceed the software life cycle, Such an object is an entity object. For example, for an order, each order will have a unique and constant identification – order number. No matter how the status and attributes of the order change, the life cycle of the order or that order will run through or even exceed the whole e-commerce business.

Value object: value object is an object identified by object attribute value. It combines multiple related attributes into a conceptual whole, which is used to describe a specific aspect of the field, and is an object without identifier.

5、 Build aggregation

Entity and value objects are just individualized business objects, which show individual behavior and ability. In the domain model, we need an organization that gathers these closely related individual objects and completes specific business functions together according to the unified business rules within the organization. Therefore, there is the concept of aggregation.

In DDD, aggregation is a group of closely related domain objects. Its purpose is to ensure the invariance of business rules within the boundary. The aggregation root has a global identity. All modifications to objects in the aggregation can only be made through the aggregation root. Aggregation helps us simplify the complex object network and gradually achieve “high cohesion and low coupling”.

From a technical point of view, aggregation is composed of entities and value objects closely related to business and logic. The modification of data in the aggregation must be uniformly organized by the aggregation root to ensure that each data modification is completed according to the unified business rules in the aggregation. Aggregation is the basic unit of data modification and persistence.

For example, an order is an aggregation, which is composed of multiple entities such as order basic information, commodity information, address information and invoice information. Each time you modify commodity data in order aggregation, they must comply with the business rule of order aggregation: “the total order amount is equal to the sum of all commodity details”, If this rule is violated, there will be many problems such as inconsistent aggregate data.

DDD practice (1) - event storm landing process

image.png

6、 Delimitation context

Boundary context is the boundary of business context. Within this boundary, when we communicate a business concept, there will be no understanding and cognitive ambiguity (ambiguity). Boundary context is an important guarantee of unified language.

There is a very vivid definition of the clearance context:

Cells exist because the cell membrane defines what is inside the cell and what is outside the cell, and determines what substances can pass through the cell membrane

An aggregation may be a boundary context with minimum granularity. At the same time, we often merge aggregations with high business relevance.

DDD practice (1) - event storm landing process

image.png

In the future technical implementation, it should be avoided as far as possible that two business requirements within the boundary context that are easy to be confused conceptually should be developed and maintained by the same team.

7、 Combing bounded context dependencies

By analyzing dependencies, it is a means to identify dependency contradictions in advance and reduce low-level design errors. Each bounding context will not contain full information, so the source direction of supplementary information is the dependent direction, or the “known” direction (I need to know its existence)

Operation steps:
  1. Collective analysis and discussion, and draw the dependency relationship between different gauge contexts by using the solid line with arrow and taking the dependency direction as the arrow direction.
  2. If the following dependencies occur, it is necessary to consider whether there are unresolved issues:
    a. Two way dependency: there is a lack of an undefined context between contexts, or the two contexts can actually be combined into one;
    b. Circular dependency: when any context changes, the context on the dependency chain needs to be changed;
    c. Too long dependency: the information of self dependency cannot be obtained directly from the dependency, but needs to be obtained and transmitted from its dependent context through the dependency. If the dependency link is too long and any context on the dependency chain changes, any context behind the chain can need to be changed;
DDD practice (1) - event storm landing process

image.png
[attached] the mapping relationships between bounded contexts mainly include the following:
  • Partnership: a relationship in which two contexts work closely together, one prospers and the other loses.
  • Shared kernel: a model in which two context dependent parts are shared.
  • Customer supplier development: organized upstream and downstream dependencies between contexts.
  • Conformist: the downstream context can only blindly rely on the upstream context.
  • Anticorrosion layer: one context interacts with another through some adaptation and transformation.
  • Open host service: defines a protocol to allow other contexts to access this context.
  • Published language: usually used with OHS to define the protocol of open hosts.
  • Big ball of mud: mixed context with unclear boundary.
  • Separate way: two completely unrelated contexts.

8、 Dividing problem sub domain and establishing service map

Operation steps
  1. From the perspective of “each problem sub domain is responsible for solving a business problem with independent business value”, the business problems to be solved in the sub domain can be clarified and analyzed through questions, such as “how to manage inventory? (English description is similar to how to…?)”.
  2. Use the dotted line to draw the boundary context for solving the same business problem together in the form of cut image, and name each sub domain in the form of “XXX sub domain”.
  3. Determine the subdomain type of each subdomain according to the definitions of the three types of subdomains and in combination with the business reality (or refer to the elevator speech in design thinking).
Key points:

● the problem subdomain and the boundary context are two completely different dimensions. The problem subdomain solves the problem of problem clarification and prioritization, and the boundary context solves the problem of business boundary identification and unified language. Therefore, there is no sequence relationship and inclusion relationship in concept. The two diagrams are put together to facilitate design and analysis, It can be understood as “superposition” or “mapping” of two graphs.
● there is a debate in the industry about the mapping relationship between the problem sub domain and the boundary context (whether it is a one to many relationship or a many to many relationship). After a lot of practice, combined with operability and ease of understanding, we deliberately choose and agree on the following mapping relationship:
○ a sub domain can contain multiple bounding contexts
○ a clearance context should not span multiple sub domains. The judgment of sub domain types will change with the switching of perspectives. For example, the support domain identified from the global perspective belongs to the core domain of the team from the perspective of the team responsible for the development of the support domain.
● you can identify the core domain first, and then the general domain. In this way, all the remaining domains are support domains.

DDD practice (1) - event storm landing process

image.png

Here we have completed the event storm practice of building the e-commerce domain model.