This content originally appeared on Level Up Coding - Medium and was authored by Yurko
In the previous post, we covered bounded contexts in DDD and a few examples of why it’s important to have a clear separation between them. This time let’s try to understand the domains and their divisions.
Domain, Subdomain, and Core domain
The Domain is what an organization does and the environment in which it operates. A software developer working for an organization must work within its domain. It is important to understand that when developing a model of the domain, it is necessary to focus on a specific subdomain, as it is almost impossible to create a single, all-encompassing business model even for moderately complex organizations. It is very important to divide models into logically separated subdomains according to their actual functionality. Subdomains allow different parts of the domain necessary to solve a particular problem to be identified more quickly.
It is also necessary to be able to identify the Core domain. This is a very important aspect of the DDD approach. The Core domain is a subdomain that has primary importance for the organization. From a strategic point of view, the business should be distinguished by its Core domain. Most DDD projects focus precisely on the Core domain. The best developers and experts should be involved precisely in this subdomain. Most investments should be directed precisely here to achieve business advantage and gain the greatest profit.
If a specific aspect of the business is being modeled that is important but not part of the Core domain, then it belongs to the Supporting subdomain. The business creates a Supporting subdomain because it has a specialization. If it does not have a specific purpose for the business and is required for the entire business as a whole, then it is called a Generic subdomain. These types of subdomains are important for business success, but they are not of primary importance. It is the Core domain that must be implemented perfectly, as it provides a business advantage.
This is the foundation for strategic design in the DDD approach.
Problem and Solution Domain
Domains consist of the problem space and solution space. The problem space allows one to think about the strategic business problem that needs to be solved, while the solution space focuses on how software is implemented to solve the business problem.
- The problem space is a part of the subject area that is necessary to create the core meaning. It is a combination of the core meaning and sub-domains that this core should use.
- The solution space is one or several limited contexts, a set of specific software models. The developed limited context is a specific solution, a representation of implementation.
The ideal option is to ensure clear correspondence between sub-domains and limited contexts. Thus, the problem and solutions paces are combined, and domain models are identified in clearly defined areas depending on the set goals. If the system is not developed from scratch, it often represents a big mess where sub-domains intersect with limited contexts.
In Vernon’s book, an example is given of a core concept for a small retail company that operates online. Any online store can improve its position by using a forecasting mechanism that analyzes sales history and inventory data to predict demand and determine optimal inventory levels. (The company should not waste money on products that have no demand and take up additional warehouse space.) It is this core concept that makes the organization much more competitive, able to quickly identify profitable deals and guarantee the necessary inventory levels. The problem space consists of the core concept and subdomains related to procurement and inventory, which are depicted in this figure:
This is only a part of the domain, not the entire domain in which the organization operates. The solution space needs to be analyzed. The acquisition model described in the figure above represents a solution for the domain. The domain model will be implemented in an explicit, limited context — “Optimal acquisition context”. This limited context clearly corresponds to the core concept.
Another limited context called “Purchasing” will be developed to refine the technical aspects of the purchasing process and will play a supportive role in relation to the optimal acquisition. It will provide interaction with the open interface of the ERP system. The purchasing context and ERP module are combined into a purchasing sub-domain. The ERP module is a non-specialized sub-domain, as it can be replaced with any other commercial acquisition sub-domain. However, it becomes a service sub-domain when viewed together with purchasing context and purchasing sub-domain.
According to the figure, the “optimal acquisition context” must also interact with the inventory context, which manages storage units. It uses the ERP inventory module, which is within the service sub-domain of inventory. The ERP application consists of various modules, which we consider as logical sub-domains — inventory and purchasing. These modules, inventory, and purchasing contexts are combined into service sub-domains.
To evaluate the problem space, it is necessary to:
- Determine what the strategic core is.
- What concepts should be considered part of it?
- List the service and non-specialized subdomains.
Evaluating the problem space affects the evaluation of the solution space. It is necessary to think in terms of physically separate organic contexts for which a unified language is sought. Therefore, it is important to:
- Analyze existing software for potential reuse.
- Determine what tools should be purchased or created.
- Study the integration of these tools.
- Determine how concepts and data from different limited contexts overlap.
- Determine which limited context contains concepts related to the core and what tactical patterns are used to model it.
The limited context consists not only of the domain model but also includes the database schema if it is created from the model. However, if the schema already existed and violates the project, it does not belong to the limited context.
The user interface that expresses the model also belongs to the bounded context. Service-oriented endpoints can also be implemented within the boundary. Both the UI components and the service endpoints are delegated to application services, which act as a facade to the model. These services are also within the bounded context.
Bounded contexts can vary in size, but the key is to demonstrate the richness of a unified language within the context. The model should contain as many domain concepts as needed to model within the bounded context — no more, no less. To ensure that nothing essential is missed, a clear and good criterion should be found. A context map can be used for this purpose. This leads us to the third important strategic design pattern.
Context Map
Following the DDD approach, a specific team should create its own map that reflects the solution space in which that team operates. This map consists of bounded contexts, as well as integration links between them. For example (famous in DDD cargo contexts):
This Context Map reflects the current state of affairs, not what will be in the future. It is necessary to avoid formalities in the process of creating the map. Too much detail only hinders the creation process.
The natural course of events is the coincidence of context boundaries with the team’s organizational division. People working together share one common model context.
After creating a preliminary context map, it can be detailed by defining relationships between contexts.
There are relationships between bounded contexts and individual project teams:
- Partnership. When teams in two contexts succeed and fail together, a collaboration relationship arises. They must collaborate in the process of evolving their interfaces to take into account the needs of both systems.
- Shared kernel. The common part of the model and code forms a close connection. A clear boundary of the subset of the subject area model, which teams agree to consider common, is indicated. The kernel must be small. It cannot be changed without consulting another team. It is necessary to coordinate a common language for teams.
- Customer-supplier development. When two teams are in a “superior and subordinate” relationship, the superior teams take into account the priorities of the subordinate teams.
- Conformist. When two teams are in a “superior and subordinate” relationship, and the superior team has no reason to consider the needs of the subordinate team. The subordinate team takes into account the complexity of translation between bounded contexts, unquestioningly obeying the model of the superior team.
- Anticorruption layer. If management and communication do not correspond to the common kernel, partnership, or “customer-supplier” relationship, then the translation is difficult. The subordinate client must create an isolating layer to ensure its system with the superior system in terms of its subject area model. This level communicates with the other system using an existing interface without requiring or almost not requiring modifications to the other system.
- Open host service. The protocol that provides access to the system as a set of services is defined. To accommodate new integration requirements, this protocol is extended and refined.
- Published language. Translation between the models of two bounded contexts requires a common language. A well-documented common language that can express the necessary information about the subject area is used as a communication environment, translating information from another language to it as necessary.
- Separate ways. If there is no important relationship between two sets of functional capabilities, they can be completely disconnected from each other. Integration always comes at a high cost, and the benefits are sometimes not worth it.
- Big ball of mud. There are parts of the system where models are mixed and boundaries are erased. It is necessary to draw the boundary of such a mixture and name it a big ball of mud. (Note: “models” here refers to software architecture models or design patterns.)
Example of the context map
A development example of a context map can be taken from Alberto Brandolini’s article “Strategic Domain Driven Design with Context Mapping”.
First, a simple context map is drawn with boundaries and connections between bounded contexts.
In these two contexts, there are differences in concepts with the same name. For example, Account in Web User Profiling refers to a user account (login and password). At the same time, for PFM Application (Personal Finance Management), it is a summary describing the current state of the client from the bank’s point of view. Sometimes, as mentioned above, the same concept can be used in completely different contexts, thereby requiring different models for them.
For example, PayeeAccount is the same as BankingAccount but with different behavior (you cannot get the balance). Thus, a separate expense tracking context will be created. Also, in the given example, a separate context for online banking services is created (such services as bank statement printing, for example).
After the first step of creating the map, it is possible to detail all relationships. Each relationship has a direction. Upstream relationships affect downstream relationships, but the reverse may not be true.
The detailed map looks like this:
The context of the bank’s online services provides an API (which could be a publicly available service with an open protocol and a common language). When this API is changed, the personal finance management context must immediately adapt to work with the new API. However, a anti corruption layer must be used to prevent concepts from the online services context from leaking into the personal finance management context (domain model transformation is used).
Since the web user profiling context is used as a ready-made external module and is delivered “as is”, a conformist relationship is established here (the downstream context obeys the upstream context).
In the case of the expense tracking context, a partnership relationship is the best fit, as there are common goals and concepts, but there is no directional relationship.
This is a simple example of a context map, but in reality, it can be much more complex.
Keep coding and have one.
— — — — — — —
Part 3 of the DDD series can be found:
https://medium.com/gitconnected/bounded-contexts-in-ddd-d5f0dc7d1cf1
Level Up Coding
Thanks for being a part of our community! Before you go:
- 👏 Clap for the story and follow the author 👉
- 📰 View more content in the Level Up Coding publication
- 💰 Free coding interview course ⇒ View Course
- 🔔 Follow us: Twitter | LinkedIn | Newsletter
🚀👉 Join the Level Up talent collective and find an amazing job
Domain and Core Domain in DDD was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Yurko
Yurko | Sciencx (2023-03-13T02:55:21+00:00) Domain and Core Domain in DDD. Retrieved from https://www.scien.cx/2023/03/13/domain-and-core-domain-in-ddd/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.