Definition of bounded context
What is a Bounded Context? Let’s read a sentence wǒ yǒu kuai di. Different people will understand different meanings, such as “I have express”, “I have a piece of land”. Can we be sure of the exact meaning? We can’t be sure, so we have to take the speaker’s tone and context to understand. For example, I have express delivery, sent by a friend. I have a piece of land. It belonged to my family. In everyday conversation, the tone and Context of the speech is the Context that helps us understand the meaning of the conversation. When we understand the domain requirements of the system, we also need to rely on such context. The definition of Bounded context is to outline this context with a clearly visible boundary, so as to maintain the consistency and integrity of the domain model within its own boundary. Eric Evans describes the cell as a limiting context because “the cell is able to exist because the membrane defines what is in the cell and what is out of the cell, and determines what can pass through the membrane.” Here, the cell represents the context, and the cell membrane represents the boundary surrounding the context.
Therefore, to understand Bounded Context, we need to understand it from the meanings of the words Bounded and Context, which represent the scene fragments of business processes. The entire business process is made up of many activities with timing, and as the process progresses, different activities require the participation of different roles, causing the context to switch as an activity occurs. Therefore, Context is actually the product of dynamic business processes being statically segmented by boundaries. A Bounded Context defines the application scope of each model, ensuring the consistency of domain models in each Bounded Context. The domain model may not guarantee consistency in different bounded contexts. Typically we set the boundaries of the model according to the organization of the team, the usage of each part of the software system, and the physical representation (such as component partitioning, database schema).
How to identify the bounded context
Consider a business scenario like this: I as a consulting go from chengdu to shenzhen do domain driven consulting for clients, both in terms of the home by subway arrived at chengdu shuangliu airport, or on a plane arrived at shenzhen baoan, again from the baoan airport taxi arrived at the hotel, my identity is a Passenger (Passenger), although because of the different traffic tools, participate in the activities are also different, But getting on, getting off, checking in, checking in, boarding and deplaning are all about transportation. So does the fact that I’m sitting on a vehicle necessarily mean that I belong to this context? Not necessarily! Notice that in the context of traffic travel, the concept of “I” is blurred and the concept of “passenger” is emphasized, which is the Role or “identity” involved in this context.
For example, when I was on the plane, IT suddenly occurred to me that the consulting plan I provided to customers needed to be improved, so I took out my computer and continued to think about my domain drive design plan at an altitude of 10,000 meters. At this time, although I was still on the plane, MY identity was changed to a Consultant. When I took a taxi to my hotel as a passenger and went to the front desk to check in, I “took off my passenger mask” and became a Guest. The next morning, AFTER breakfast in the hotel restaurant, I left for the client office. As I walk out of the hotel, the hotel context switches back to traffic. When I arrived at the location of the client, I began to talk with the client team as a consultant to understand their consulting goals and existing pain points. I make consulting plans and proposals and review them with the client, and the context switches to consulting. Coincidentally, both transportation travel and hotels need to pay fees. Although the fees paid are different, the payment behavior is also different, and the domain knowledge needed is the same. Therefore, this activity can be classified as the payment context.
Context switching in the process is just like scene switching in a movie screen. The same characters play different roles and participate in different activities in different contexts. As the objectives of the activities change and the responsibilities are different, the above scenarios are shown below:
This semantic environment in the real world corresponds to the bounded text in DDD
Therefore, there are several key points to take into account when understanding a bounded context:
Knowledge: Different bounded contexts require different domain knowledge, which is really business relevance, and participation in bounded contexts is also related to “knowledge.” If the activity is performed without corresponding knowledge, it indicates that the allocation of the activity is not reasonable; If the goal of the activity is consistent with the bounded context, but the knowledge is lacking, then the activity needs to work with another bounded context. Roles: Be sure to think deeply about what roles the objects participating in this context play and how roles and roles work together in this context. Boundary: the boundary context is separated according to different concerns, and the respective boundary is determined according to the strength of the coupling relationship. The weaker the relationship is, the more the boundary needs to be delimited. We need to categorize these activities in terms of business relevance, coupling strength, and separate concerns, and find the boundaries that exist between the different categories, which is what a bounded context means. Context is a business goal, and Bounded is to protect and isolate the boundaries of Context, so as to avoid the confusion and conceptual inconsistency caused by the diversity of business goals.
Third, the value of the context
Eric Evans introduced the concept of bounded context in strategic design. He believed that:
If you can’t maintain a unified model that covers the entire enterprise, don’t be constrained by this kind of thinking. By deciding in advance what should be unified, and actually recognizing what can’t, we can create a clear, common view, and then need a way to mark the boundaries and relationships between the different models.
To solve the problem of multiple models, we need to clearly define the scope of the model — the scope of the model is a bounded part of the software system that applies only one model and keeps it as uniform as possible. This definition must be adhered to consistently throughout the team organization.
Clearly define the context in which the model is applied. The boundaries of the model are set according to the organization of the team, the usage of various parts of the software system, and the physical representation (code and database schema, etc.), and the consistency of the model is strictly maintained within these boundaries, without interference and confusion from issues outside the boundaries.
Based on the three descriptions cited above, we can clearly outline Eric Evans’s focus on bounded context, which is the control of boundaries. If the context is a state, then the king of the realm should defend his territory, every inch of which is sacrosanct. Therefore, to understand the value of a bounded context, we must understand it from the perspective of boundaries.
The boundary demarcated by the bounding context is also different depending on the perspective of observation. It can be roughly divided into the following three aspects:
Domain logic: the bounding context determines the business boundary of domain model, maintains the integrity and consistency of the model, and thus reduces the business complexity of the system. Team cooperation level: The bounding context determines the working boundary of the development team, establishes the cooperation mode between teams, avoids the confusion of communication between teams, and thus reduces the management complexity of the system. Technical implementation level: bounded context determines the application boundary of system architecture, ensures the consistency of system layer and context domain layer, and establishes the integration mode between contexts, thus reducing the technical complexity of the system. These three kinds of boundaries reflect the control power of the bounding context to different boundaries. Business boundary is the control of domain model, work boundary is the control of development collaboration, and application boundary is the control of technical risk. The purpose of introducing bounding context is not how to divide the boundary, but how to control it.
One of the core values of bounded contexts is to use boundaries to constrain domain models in different contexts to ensure the consistency of models. However, each bounding context does not exist independently, and most of the time, multiple bounding contexts need to work together to complete a use case scenario. For example, the core process of “buying goods” can only be completed through the integration of customers to goods, goods to orders, and orders to payment.
The relationship between two bounded contexts is directional, and domain-driven design uses two specialized terms to describe them: Understanding the relationship between “Upstream” and “Downstream”, in the context map, with U representing Upstream and D representing Downstream, just as understanding the metaphorical river of the term means that changes made Upstream will naturally affect Downstream and vice versa. Therefore, the direction of the relationship from upstream to downstream represents the force exerted by the influence. The direction of the influence force is exactly the opposite of the dependence direction commonly understood by programmers. The upstream affects the downstream, meaning that the downstream depends on the upstream.
