|0x00 What is the domain model
What is the domain model? In a word: The "economic foundation" in "the economic foundation determines the superstructure" is the cornerstone to help understand the problems of complex business areas.
Someone said: "Domain model is a business concept. Enterprises in the same industry must have inherent commonalities. It is a tool to help system analysts understand the real business." Domain means the boundary. With a clear boundary, collaboration can only be achieved. The foundation of interest; the model, that is, the knowledge system, has a deep understanding of business knowledge, and development will not make too many detours. The domain model in the general sense is oriented to the field of software engineering, while the domain model in the practical sense includes broad concepts such as business models.
When many people come to understand Domain Driven Design (DDD), they are basically at a loss, because the original intention of model design is not to focus on software concepts such as performance, architecture, and layering, but to start from abstract concepts such as boundaries and cohesion. Speaking. Understanding the domain model is not to learn through technical thinking, but to train one's thinking consciousness through continuous practice, and then thoroughly form a structured and object-oriented thinking methodology.
The domain model does not directly bring benefits, but only assists us in understanding what we are doing.
To quote Baidu, "A domain model is a visual representation of conceptual classes in the domain or objects in the real world. It is also called conceptual model, domain object model, and analytical object model. It focuses on analyzing the problem domain itself and exploring important business domains. Concepts, and establish the relationship between the concepts of the business domain." To sum it up, it means "describe the problem accurately and describe the plan clearly."
If the essence of software development is the transformation from the "problem space" to the "solution space", then the "domain model" is the architecture of the "solution space", which brings a unified cognition to the system through abstract models .
|0x01 How to design the receiving model
Before designing the domain model, we must first determine the "problem space", that is, to analyze and disassemble the requirements. It is worth noting that the domain model is usually for the design of a relatively large system. If it is a small requirement in the daily function iteration, then only need to do the corresponding development according to the principles of the designed model.
What needs to be done in the requirement analysis phase is to determine what the core functions of the system are to be realized. UML is a very good tool to express design intent. UML can clearly explain the core responsibilities and processes of the system through the combination of dynamic and static diagrams.
- Class diagram: static, showing the existing classes in the model, their internal structure, and their relationship with other classes;
- State machine: dynamic, modeling the behavior of a single object, specifying the order of execution of related events when the object responds to different events throughout its life cycle;
- Sequence diagram: dynamic, describing the time sequence of sending messages between objects and showing dynamic collaboration between multiple objects.
Next, is the business modeling stage. In most domain-driven books, the domain is divided into: domain, subdomain and bounded context. A domain is all things included in a model; a subdomain refers to a subdivision of the model, which can be divided into core, support, and general according to importance; bounded context is a business boundary, and the terms within the boundary have their specific Meaning, for example, customers in the banking system and e-commerce system do not mean the same thing. This division method is usually very flexible and has a greater relationship with the designer's personal experience.
After the system is split, it is necessary to determine the relationship between the subdomains/contexts and how the information between each other is transferred, for example:
- Model concept
- Model attributes and attribute values
- Relationship between models
Finally, it is through some specific methodology to analyze the specific model design. There are also many design methodologies. For example, in the use case analysis method, it is to collect use case materials as much as possible, and graphically describe the system as use cases, participants (users) and the relationships between them through example diagrams; In DODAF, a standard method is used to express the guidelines of "EA's data and relationship types" to solve the structural problems of complex systems. In the four-color modeling method, blue represents commands, red represents entities, green represents domain events, and yellow represents supplementary information, and related entities can be sorted into the same domain. There are many modeling methods, whether it is the existing methodology or the design through the accumulation of daily business experience, as long as the model can be described clearly, it is available.
To summarize, set aside the technical perspective and use a purely business perspective to build the model. But what is certain is that the priority of the domain model is higher than that of the software solution. First, there is the overall framework of domain modeling, and then the model is mapped to the software architecture.
|0x02 The value of the domain model
Modeling is a complex team work. After a long period of exploration, several characteristics can be summarized:
- When modeling, do not start designing specific models immediately, but analyze and disassemble the business first; in many cases, business personnel are not necessarily very familiar with the business, and the process of preliminary research is essential.
- In order to avoid ambiguity, it is best to use unified terminology and tools, such as UML, in the modeling process.
- Learn to adapt to changes, and the model itself will change. The frequency of changes depends on the speed of business development. The current form is an intermediate state in a sense.
A good software system needs to make trade-offs before meeting business requirements and the underlying system architecture at the same time. Product operations often do not have a technical background. Therefore, there are often fierce conflicts between "do or not" and "how to do". More often, both parties have different understandings of the same concept. This GAP is not necessarily a "big-to-the-sky" difference, but a misunderstanding of some specific details, but this kind of details Often very fatal. At this time, it is much more effective to use the model to reflect the actual business situation, which is equivalent to the role of the manual, to communicate with the demand side.
Therefore, from a global perspective, the domain model will bring the following values:
- Unified language: smoother communication and easier resolution of differences;
- Knowledge precipitation: through the familiarization process of the business domain, it can be precipitated in the form of a model, which is helpful for self-improvement and team inheritance;
- Keep it clear: When communicating requirements, you can quickly clarify which requirements are reasonable and which are against business rules, so that the business can run faster while maintaining a clear system structure.
|0xFF Digital Transformation
After reading the previous content, most people will have a question, that is, where does the domain model apply? In most Internet scenarios, the domain model is used, which makes the business more complicated. In fact, since Eric Evans published "Domain Driven Design: The Way to Deal with the Core Complexity of Software" in 2003, the concept of the domain model has been deeply rooted in people's hearts, and the development of the Internet is not sufficient. As more and more companies realize the importance of digitalization in recent years, how to use data to drive the development of specific industries, such as manufacturing, has gradually become a trend. In this trend, the high probability of innovating traditional industries is not people who come out of traditional industries, but people who have mastered digital technology. How can technical people quickly understand and penetrate an unfamiliar industry? The domain model naturally comes in handy.
For example, the common productivity tools ERP and MES in the information age can solve many problems of informatization, but they are not so applicable to the process of production circulation, especially after 5G, many devices also have digital features. The new management system with "data flow" as the main feature is necessary to adapt to and replace the original production system. However, the past "data flow" relied on the Hadoop system and dimensional model. This organizational method was applied to the past management system, which would cause a lot of incompatibility. Therefore, the domain model was used to smooth out various technical differences. , To reach a consensus for people in the traditional VS Internet industry and jointly promote system transformation, creating a foundation.
