Domain-Driven Design: strategic design. Part 1

Hello, habra users! This article will focus on domain-specific software design using, first and foremost, strategic patterns. The second part - about tactical design - read here .

This approach was used by Von Vernon in his book “Implementing Object-Based Design Methods”. The purpose of writing this book: to give developers the opportunity to fly on a DDD plane (as a child, the author often traveled with his family on small planes). The view from the height gives a broader view of the problems of modeling, without letting you get stuck in various technical details. By observing the DDD landscape in this way, one can realize the benefits of both strategic and technical design. Read more - under the cut!
')
The flight is carried out using the tools and templates of strategic modeling, such as: a , a , a , a , a , . It is about them that will be discussed in this article.

Designing using tactical templates, such as, for example, an , , a , a , an , an , is a lightweight DDD. Although it is very important to be able to use this approach, these templates are mostly technical in nature, and in order to see the big picture of DDD, you must first learn how to apply strategic patterns in practice.

The main purpose of using DDD is to obtain a high-quality software model that will most accurately reflect the business goals set. To implement this, it requires the combined efforts of both developers and subject matter experts. Creating a friendly and cohesive team allows you to get a large number of business benefits. The exchange of knowledge between team members reduces the chances of a “secret knowledge” about the model, a consensus is reached between subject matter experts on different concepts and terminology, a more precise definition and description of the business itself is developed.

In order to equalize the developers and domain experts, to make it much easier to exchange useful knowledge about the subject area, the DDD approach suggests applying a common set of terms, concepts and phrases that will be used in communication between team members, and which later will be reflected in the source code of the resultant programs.

Common language

This collective language of terms is called a (Ubiquitous Language). This is one of the main and most important patterns of subject-oriented design. This is not business jargon imposed on developers, but a real language created by a holistic team — subject matter experts, developers, business analysts, and everyone involved in creating a system. The role in the team is not so significant, since each team member uses a to describe the project. The process of creating a single language is more creative than formal, since it, like any other natural language, is constantly evolving, and those artifacts that initially contributed to the development of a useful single language will eventually become obsolete. As a result, only the most stable and proven elements remain. To move from experiments to accurate knowledge, Von Vernon in his book suggests using the following methods:

1. Creating charts of the physical and conceptual subject areas and putting labels on them denoting names and actions. Such diagrams are informal, so there is no point in using formal modeling (like UML).
2. Creating a glossary with simple definitions, as well as alternative terms with an assessment of their prospects. Thus are developed stable phrases of a single language.
3. Create documentation instead of a glossary. This documentation will contain informal charts or important software related concepts.
4. Discussion of ready-made phrases with the rest of the team members who cannot immediately master the glossary or other written documents.

Since the code will be developed quickly enough and it needs to be coordinated with the current version of a single language, then you can later abandon the diagrams, glossary or other documentation.

The most important thing for a developer is the ability to listen to experts, to get the maximum amount of useful knowledge about the subject area. At the same time, experts should also listen to the developers and their wishes. A team learns and grows together if it acts together, gaining a deeper understanding of the business.

I will give a few examples from the book:

In a team, discussing a model for using a flu vaccine in the form of a code, utter a phrase like: "Nurses prescribe flu vaccines in standard doses." Possible scenarios:



Obviously, the first option is far from optimal, the second is better, but does not take into account some important concepts. The final version is most suitable for the task.

It is very important to understand that, within the domain, the meaning of a certain term or phrase can be very different. There is a certain limit within which concepts
single language have a very specific contextual meaning.

Limited context

This conceptual boundary is called the . This is the second most significant DDD property after a single language. Both of these concepts are interrelated and can not exist without each other.

So, a is an explicit boundary within which there is a domain model that maps a to a software model.

• In each limited context, there is only one .
• Limited contexts are relatively small, less than it might seem at first glance. is large enough only for a single language of an isolated subject area, but no more.
• Single means “omnipresent” or “ubiquitous,” that is, the language spoken by team members and which express a separate domain model that the team develops.
• The language is one only within the team working on the project in a single limited context.
• Attempting to apply a across the entire enterprise, or worse, among several enterprises, will end in failure.

For example, consider the contrast between terms of the summary (assount) in the context of banking services and in the literary context:

Banking Context

The summary maintains a record of receivables and payables that reflect the current financial condition of the client from the bank’s point of view → A summary of current accounts or a summary of savings accounts

Literary context

A summary is a collection of literary expressions about one or more events that have occurred over a certain period of time → Into Thin Air is sold on amazon.com: A Personal Account of the Mt. Everest Disaster

It is not possible to distinguish bulletin types by name. But they can be distinguished only by the names of their conceptual containers, i.e. relevant restricted contexts.

These limited contexts belong to different . In the following example, the same name is used within the same .

In some publishing houses books go through different stages of the life cycle, that is, the book goes through different .

• Concept development and proposal for publication
• Contract with the author
• Editorial process management
• Development of a book layout, including illustrations
• Translation of the book into other languages
• Release of paper and / or electronic versions of the book
• Marketing
• Selling a book to resellers and / or directly to customers
• Delivery of copies of the book to resellers or customers

In this case, there is no only way to develop the right book model. For example, before the conclusion of a contract, the title of the book remains uncertain and may change during the editing process. Marketing does not require most of the artifacts of literary and technical editions, with the exception of covers and annotations, and only the name, location of the warehouse, the number of copies, size and weight are needed to sell the book. To avoid confusion, the DDD approach requires the use of separate for each of the stages of the life cycle. The model of the book in each would be significantly different from all others. Each team of a specific talks about the book and knows exactly what it wants for its .

In the example above, various are used within one .

Subject area, subject subdomain, semantic core

Domain is what the organization does and the environment in which it does. A software developer for an organization necessarily works in its . It should be understood that when developing a domain model it is necessary to concentrate in a specific , since it is almost impossible to create a single, comprehensive business model of even a moderately complex organization. It is very important to separate the models into logical divided entire , according to their actual functionality. allow you to quickly determine the different parts of the needed to solve a specific problem.

It is also necessary to be able to determine the (Core domain). This is a very important aspect of the DDD approach. is a primary importance for the organization. From a strategic point of view, business should be distinguished by its . Most DDD projects focus specifically on the . The best developers and experts should be involved in this particular . Most investments should be directed here to achieve business benefits and maximize profits.

If a certain aspect of a business is being modeled, which is important, but is not a , then it belongs to Supporting subdomain. A business creates a because it has a specialization. If it does not have a special purpose for business, but is required for the business as a whole, then it is called a (Generic subdomain). These types of are important for business success, but they are not of primary importance. It is the to be implemented perfectly, because it provides an advantage to the business.

This is the basis for strategic design with the DDD approach.

Problem space and solution space

consist of a problem space and a solution space. The task space allows you to think about a strategic business problem that needs to be solved, and the solution space focuses on how the software is implemented to solve the business problem.

• The task space is part of the that is needed to create the . This is the combination of the and that this core should use.
• Solution space - one or more , a set of specific software models. The developed is a specific solution, a representation of the implementation.

The ideal option is to provide a one-to-one correspondence between and . Thus, the task space and solution space are combined, domain models are allocated in well-defined areas, depending on the goals. If a system is not developed from scratch, it often represents a , where intersect with .

As an example, the Von Vernon book provides a for a small company that sells online retail. Any online store can improve its position if it uses a forecasting mechanism that will analyze sales history and inventory data to obtain a forecast of demand and specific amounts of optimal stocks. (A company should not spend money on products that do not have demand and occupy additional storage space.) It is this makes an organization much more competitive, able to quickly identify profitable transactions and guarantee the required level of inventory. The task space consists of a and related to purchasing and stocks, and which are displayed in this figure:

This is only part of the , not the entire in which the organization operates. The task space (semantic core and subdomains) needs to be analyzed. The procurement model shown in the figure is a solution for the . The domain model will be implemented in an explicit : the context of optimal procurement. This unambiguously corresponds to one called the semantic core of optimal procurement. Another called procurement context will be developed to clarify the technical aspects of the procurement process and will play a supporting role in relation to the context of optimal procurement. They provide interaction with the open interface of the ERP system. The procurement context and the ERP procurement module are combined into a procurement service area. The ERP module itself is a , since it can be replaced with any other commercial procurement system. However, it becomes a if it is considered in conjunction with the procurement context in the procurement subarea. In accordance with the figure, the optimal purchasing context should also interact with the inventory context that manages the storage units. It uses the ERP inventory module, which is located within the inventory area. An ERP application consists of various modules that we consider to be logical — these are inventory and purchases. These modules and contexts of stocks and procurement are combined into .

So, to evaluate the problem space, first of all you need:

• Determine how the strategic looks like.
• What concepts should be considered as part of the
• List and .

Estimation of the problem space affects the estimation of the solution space. Here it is necessary to think about existing and new systems and technologies. One must think in terms of clearly separable physical for which a is sought. Should:

• Analyze existing software for reuse
• Identify funds to be acquired or created
• Examine the integration of these tools.
• Determine how concepts and data of different overlap
• Determine which contains concepts related to the , and which tactical patterns are used to model it.

consists not only of the model. Although the model is its main component. If you create a database schema from a model, it also participates in this . At the same time, if the scheme existed before and the project was broken in it, this scheme does not belong to a .

that expresses the model also applies to a . Service-oriented endpoints that are also within the boundary can also be implemented. Both user interface components and service-oriented endpoints are delegated to , which act as a to the model. These also within the .

Sizes of can vary widely. The main thing is for the model to demonstrate the richness of a in . It should have as many concepts as necessary for modeling within a — no more, no less. In order not to miss anything substantial, you need to find a clear and good criterion. For this you can use . Thus, we come to the third important strategic design pattern.

Context Map

Following the DDD approach, a certain team must create its own , which reflects the solution space in which this team is located. This consists of as well as integration links between them. Example:

This Context Map shows the current state of affairs, not what will happen in the future. It is necessary to avoid formalities in the process of creating a . Too many details only interfere with the creation process.

The natural course of events - the coincidence of the boundaries of contexts with the organizational division of the team. People working together share one common context of the model.

After creating a preliminary , it can be detailed by determining the relationship between .

There are such relationships between and individual project teams:

• (Partnership). When teams in two succeed and fail together, a cooperative relationship arises. They must collaborate in the evolution of their interfaces to accommodate the needs of both systems.
• (Shared kernel). . , . . . .
• - (Customer-supplier development). « », .
• (Conformist). « », . , .
• (Anticorruption layer). , , «-», . , . , .
• (Open host service). , . .
• (Published language). . , , .
• (Separate ways). , . , .
• (Big ball of mud). , , . .

An example of development can be taken from the article Alberto Brandolini Strategic Domain Driven Design with Context Mapping.

First, a simple context map is drawn with boundaries and a link between :

In these two contexts there are differences in concepts with the same name. For example, Account in Web User Profiling is a user account (login and password). At the same time, for PFM Application (personal finance management), this is a summary describing the current state of the client from the point of view of the bank. Sometimes, as mentioned above, the same concept can be used in completely different ones , thus it is necessary to define different models for them.


For example, PayeeAccount is the same BankingAccount, but with a different behavior (you cannot get a balance). This will create a separate expense tracking context. Also separately, in the example, a context of online banking services is created (on-line banking services) (such services, for example, as a printout of bank statements).


After the first step of creation , all relationships can be detailed. Every relationship has a direction. Upstream influences downstream, but not the fact that the opposite is true.

Detailed looks like this:


The context of online banking services is provided by API (it can be an open protocol service and a public language). When this API is changed, the context of personal finance management should immediately change to work with the new API. It should be used to prevent concepts from the context of online services to leak into the context of personal financial management (the transformation of domain models is done).

Since the context of web user profiles is used as a ready-made external module and is supplied “as is”, a relationship is established here (the subordinate submits to the superior).

In the case of the cost accounting context, the relationsince there are common goals and concepts, but there is no direction of attitude.

This is a simple example , in fact they are much more complicated.

Conclusion

This article discussed the basic concepts of object-oriented design through strategic patterns: , , , , , . These tools are enough to see the strategic development of the project and understand how to further develop the business in order to achieve the greatest success.

Of course, after reading this article, much still wants to clarify. To do this, I recommend referring to the aforementioned book by Von Vernon. Also for this there are special communities where you can ask for advice. Tactical same modeling techniques as well as patterns, such as , , and others will be discussed in the next article.

Thanks for attention!

The article was prepared by: greebn9k (Sergey Gribnyak), wa1one (Vladimir Kovalchuk), silmarilion (Andrey Khakharev).