Shulou(Shulou.com)06/03 Report--

Easy to learn DDD II: how to digest knowledge efficiently

I started with DDD in 2012, read Domain driven Design: how to deal with Software Core complexity several times, and also worked on projects with DDD. The general feeling is that some concepts of DDD are obscure and difficult to grasp, so I want to write a series of essays, hoping to help you understand DDD more easily. Many of the articles are my personal experience and understanding, and it is inevitable that there will be mistakes. I hope you can correct them in time and discuss and improve them together. Link to the previous passage:

Easy to learn one of DDD: model-driven Design

This is the second in a series of essays on how to digest knowledge efficiently.

1. Knowledge source

Before we talk about how to digest knowledge, we need to identify the sources of knowledge for modeling. First of all, we use the following figure to examine the relationship between several concepts, such as model, domain, software, real world, computer system and so on.

The real world (left side of the blue line) and computer system (right side of the blue line). We understand the needs of users as users require us to build a specific computer system through which users can change the real world according to their own expectations. For example, Taobao is such a computer system, through which Alibaba can make the sale of goods faster, more convenient and cheaper. Domain and software. The domain is the collection of users' needs and perceptions of the real world from the perspective of users' needs; software is the program that allows computer systems to operate in the way users expect. Domain model. It is rich in domain knowledge, bound with implementation, and can effectively couple the domain with software, so that we can quickly develop feature-rich software products based on the model.

From the above cognition, we can know that the model is the precision, structure and abstraction of domain knowledge under the constraints of user goals and software implementation technology.

two。 Knowledge digestion

Because modeling depends on domain knowledge carding under the constraints of user goals and software implementation technology, modeling requires efficient communication and cooperation among domain experts, modeling experts and software development to effectively digest domain knowledge. Below, we will explain how to do this from three aspects: communication media, communication forms and goals.

2.1 Communication Media

There can be a variety of communication media for digesting knowledge. Here are several major communication media:

Oral English: this is the best way of communication for human beings, with low cost and rich forms, and it is the most respected means of communication in eric. Words: good at accurate expression, at the same time, the conversion with spoken language is also very convenient. We use words to record the definition and interpretation of the most important concepts, behaviors, and rules in the model. UML: graphical UML is very good at expressing the relationships and interactions between objects, and can also effectively guide the coding of the OO language. However, it is not good at the definition of concepts, and it is difficult to express the behavior and constraints of objects, so it needs to cooperate with text instructions. UML diagrams contain a large number of implementation details, it is difficult to communicate efficiently based on them, and it takes a lot of work to create and maintain them, so we often use simple informal UML diagrams as the topic of discussion. Code: expressing business details through code can save us a lot of work on document writing and maintenance; at the same time, if the code can make it easy for domain experts to understand and even write, it can also make the model better bound to the implementation. However, the code is often full of implementation details, so it is difficult to express the overall and large proportion of model knowledge. Explanatory model: the technical model of user-driven software development process must be strictly simplified and restricted, so the efficiency of learning domain knowledge based on technical model is very low. The explanatory model does not have these limitations, and can be used to understand domain knowledge faster and better.

Generally speaking, we should use spoken language as the main means of communication, use words to define important domain objects, constraints and behaviors, use simplified informal UML diagrams to express the associations and interactions between domain objects, use code to carry design details, and use interpretive models to speed up the learning of domain knowledge. 2.2. The communication form of knowledge digestion

With the means of communication, we also need forms of communication. Here are some major forms of communication:

Brainstorming. When a group of people develop new ideas around a particular area of interest, this situation is called brainstorming. Brainstorming inspires new ideas and solutions through a full collision of ideas among participants, so it is ideal for use in the early stages of modeling. We can use the simplified UML diagram as the theme to discuss and refine the specific form of brainstorming, or we can use the more popular event storming method. Check the scene. We can walk through various scenarios based on the model in order to confirm that the model can well express and implement various scenarios. Scene walking is a low-cost means of trial and error, through which we can avoid the rework of software development caused by unreasonable models. Prototype feedback. When there are preliminary results in modeling, the developer can quickly implement a prototype without interface and persistent database based on the existing model to verify the effectiveness of the model, and further communicate with domain experts more intuitively based on the prototype. Modeling experts pair coding with developers. Through the pair coding with the development, modeling experts can collect all kinds of problems encountered in the process of mapping the model to code more comprehensively, so that they can better identify and correct the defects in the model. A small discussion. When the model is initially stable, the model will continue to evolve according to the changes in requirements and the deepening of understanding, and there are already several backbones in the team who can deeply understand the model, so for local changes to the model, it would be more efficient to have a small-scale discussion with them. The results of the changes can be communicated to all members of the team in various ways. 2.3. target

Undoubtedly, the ultimate goal of knowledge digestion is to build a good model, but a good model needs to be supported by a unified language and a refined model.

2.3.1. Unified language

Unified language means that all team members use unified terms to refer to domain concepts and knowledge. It has the following aspects:

Uniform terminology. This can be said to be the starting point of a unified language. The terminology is precise. Make sure that the term accurately refers to a domain concept and knowledge. When the meaning of the term is vague, the meaning is too broad, and there are different meanings in different contexts, it will often cause deviation in everyone's understanding, and eventually the unity will only be reduced to formal. Terminology understanding does not require translation. When some team members or roles (such as developers) understand the term, they translate it into another term that is easier to understand in their minds. If this is the case, please express the terms in your mind, and you will want to see again which term can better express domain knowledge. Unified spoken language, documentation and UML and other forms of language. The same concept should be unified in spoken language, document description or UML diagram, otherwise it is easy to cause misunderstanding. If some terms are not catchy, change them to a catchy term. 2.3.2 Model refinement

We know that simple and reasonable software design is the key to maintain low-cost modification in the long-term development process. In DDD, the complexity of domain model determines the complexity of software design, so model refinement is the most important goal for us to digest domain knowledge. In other words, our goal of digesting domain knowledge is not to understand all domain knowledge, but to make clear which domain knowledge is important and which is not important to meet the needs of users. Model refinement is a continuous process. As we deepen our understanding of the domain, the model will continue to be refined. As the requirements change, the most important concepts that the model focuses on will be added and removed.

3. Knowledge inheritance

It is so difficult to digest knowledge, so it is important to ensure the smooth transmission of this knowledge. Although these knowledge will be deposited in various material carriers such as our documents, UML and code, the most important carrier is the team's deep understanding of the core backbone of this knowledge, so ensuring the relative stability of these core backbones in the process of software development can ensure the effective inheritance of knowledge and finally ensure the success of DDD.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.