Write it first: DDD or no DDD

There are tons of domain-driven articles online, but as one of my colleagues said, how many have actually landed? We say domain driven the most core is the domain model, a stable domain model is better than hammering, yet in the present moment is the age of the Internet, the business told the development period, all products design and technology are in the service of the business, but how many business is follow one’s inclinations behind closed doors temporary solution, I think the programmers should be. This raises the question of how we can unify the language with the business through domain modeling when the business level is so fluid, let alone stabilize our domain model (relatively stable over time). At the same time, in the eyes of those bosses who do not know technology, they only focus on completing the development of the system through the squeeze of time, no matter how you use DDD and the increase of development cycle and development cost, they will only think that you are not good at technology, do such a simple thing takes so long. All right, enough teasing!

Since few enterprises have actually implemented DDD, do we still need DDD?

My answer: yes, we need a grip, any new system development and reconstruction of the old system and even the system technology application architecture or functional architecture diagram, all need a grip, a breakthrough point, a weapon that can move everyone’s thinking, including the separation of micro-services, what is the theoretical basis of the separation? By experience? We need a gripper out of caution, because DDD might be one.

However, although many enterprises have not actually implemented DDD, perhaps because their books and materials are too high, in fact, we have used some of the ideas and methods of DDD in our daily work. For example, aggregation is the basis for building domain models in DDD modeling. Aggregation is involved in more or less everyday technical solution design, even when we draw UML class diagrams, aggregation is one of the six relationships.

This article belongs to the practice of soft power, and the practice of internal skill is the basic quality of programmers.

A model,

The core of domain driving is domain model. Let’s talk about what is a model first.

There are many explanations in Baidu.com, and we understand them all.

A model is an object to express the purpose of objectively expound the morphological structure by means of entity or virtual expression through subjective consciousness (object is not equal to object, not limited to entity and virtual, not limited to plane and three-dimensional).Copy the code

There are several points that need to be explained from the description here. Firstly, the model does not necessarily exist in the real world. Secondly, the establishment channel of the model is our executive consciousness, that is, our brain, which is formed after thinking, but it is not nonsense, and has basis and reason. Of course, we can also directly define our model as things that exist in the objective world, and in today’s MVC development model, most companies and most programmers do that and probably think that. If software development is like this, then we are indeed the “migrant workers” in everyone’s mouth.

And the other thing that we can learn is that the range of models is very, very wide, even in any form, in any region, in any space.

Model ≠ commodity. The shape of any object is a model during the development process before it is defined as a commodity. When the model and specification are defined and the corresponding price is matched, the model will be presented as a commodity.Copy the code

I think the description of this sentence is very important. We can understand that the model is actually a product of process rather than the presentation of results. The model itself is close to business or technology, and what customers care about is the presentation of complete commercialization.

This reflects the importance of modeling from another perspective. We can directly map an object into a model and make one-to-one correspondence. We also need to do some in-depth thinking and precipitation to polish our model.

In a broad sense: if one thing can change as another thing changes, it is a model of another thing. The role of models is to express the nature of different concepts. A concept can change many models to varying degrees, but only a few models can express the nature of a concept, so a concept can change the expression form of its nature by referring to different models.Copy the code

The generalized definition tells us that the model is changing, and it is not confined to a form or a single model, and sometimes even a very responsible model can let us understand and understand a certain definition and concept, so the model itself is complex, and the modeling process is very interesting.

When a model relates to things, it produces a framework with properties that determine how the model changes with things.Copy the code

The framework is introduced here, which gives us a hint of architecture, which once again shows how important the model is, and when it is associated with the real world, the butterfly effect generated will also predict the development process and outcome of things.

Conclusion: Model is used to express the real or virtual things in the real world, to express a certain concept, so that we can obtain a certain understanding, and in the development and evolution of things in the future, we can control and stabilize the development of things through a certain framework, to prevent the emergence of the situation that we can not control.

Finally, models belong to the realm of data, so who says that the numbers of languages we learn in elementary, middle and high schools are useless? There are functions and uses everywhere, but the people who say them don’t know it.

Second, the field of

Let’s take a look at what a domain is.

Its English name is: domain

英 文 名 称 :

Refers specifically to a specific range or area.Copy the code

We draw the word “focus scope”, that is, domain model actually represents a concept, knowledge, or thing with scope. Just like when we launch a project as technical PM, we must complete one task in a certain work list within a limited time. The most important thing in project management is the project scope. Also, the most important thing in modeling in our field is to determine the scope of the model. Here are some other explanations, but the general meaning is similar:

The territory of a state's sovereignty.Copy the code

A division, division, or division of a specialized activity or enterprise.Copy the code

The scope of academic thought or social activity.Copy the code

3. Domain model

Domain-driven has several very important concepts: core domain, subdomain, generic domain, and bounded context.

Core domain: the sub-domain that determines the core competence of the product and the company, and is the main factor of business success and the core competence of the company. From this definition, we can see that the core domain is actually the most direct and unique content of our current business. For example, the APP of ordering food, then the core domain should be ordering food, food management, food release, food evaluation and food order. Other functions in the APP such as users, inventory, ingredients, payments, user orders and even accounting are either generic or support domains.

General domain: As the name implies, it has universality. In the APP of ordering food, users, inventory and ingredients belong to the general domain, which is referenced by multiple sub-domains.

Support domain: it is used to solve a certain business problem. In the ordering APP, users’ payment orders, accounts and payments are the support domain to solve a certain business problem related to APP payment.

It is important to understand the bounded context, which will also define the boundaries of our domain division. After we figure out which are the core domain, common domain, and support domain, we need to group the resulting aggregations, delimit boundaries by business cohesion and correlation, and give context names combined with context meanings. The bounding context is not one-to-one with the model, but can be composed of multiple models. Its role can be to clarify the problems solved by the model and keep the clarity of each model. The core of the domain is to determine the scope, and the bounded context is the boundary of the domain model as well as the boundary of our cognition of the domain. What we often mean by high cohesion and low coupling is that the models are closely related in one bounded context, while the other models should be in other bounded contexts.

So why is a bounded context not one-to-one with the model, but one-to-many?

Model is not omnipotent, the meaning of model is to describe real or virtual things in reality, and must be able to solve real problems. World is constantly changing, things change and development, so the reality of the problems are complex and diverse, often with one or two model also can't very clear trying to describe and solve the problem of all, this time we need to put multiple models that form a whole to solve the problem, the modeling of the whole.Copy the code

Subdomain: can solve a specific problem.

How to model the domain

There are detailed explanations of various domain models on the Internet, as well as many methods and examples of domain modeling. Here I list the methods that I think are easier to understand and better to implement. In fact, the methodology of how to model the domain is not always implemented step by step. When some domains are not clearly divided or diverging, the key to solving the problem may be found through the remolding of business processes.

All the development work is inseparable from the sorting of business processes, and then business into product language, technology will be the implementation of product design. So the first step is to draw all the core business processes. Any business has a stable business process, and the products of the nodes in the business process are our business skeleton. In general, we draw the business process in the following form:

The emphasis here is on the core business process, which can be perceived as our core business domain and can also assist in the determination of our bounded context.

After digging the first step, the next step is the re-decomposition of the business sub-process. Generally, we will form the following graph:

The simple two parts can roughly determine which domain model we have, which business can support and which problems to solve, but which are the core domain, the support domain, the general domain, and how to execute the limiting context need to be carefully divided through abstraction and analysis, combined with their respective roles.

Some peers even summed up the domain modeling method as the three-character method: find nouns, add attributes, and connect relations.

​

Five, so the end

This article does not raise real case, is not never practice, but I also found in the summary and personally think that the methodology of comparison can take over, to know later met some of the situation, but also to strengthen and uniting the internal work experience, as a programmer technology cannot be lost, but only the upper jianfa, no deep internal work methodology, How can the two be consistently competitive? In this impetuous society, the more obscure things need to calm down and summarize well, now the network process is called immersion!

In the future, I will summarize some theories that are more difficult to understand in other aspects. People are always looking for a balance point. The theories are too profound to understand and too vernacular.