DDD Original--the communication and use of language in the second chapter

a team, a language. language, the unification of terminology is very important. If the language is fragmented, the project is bound to suffer serious problems. The discussion is inconsistent with the terminology in the code, and even the same person is not consistent with the writing, resulting in a certain understanding of the field and forgetting that it cannot be recorded in the code and document. Projects require a common language, and domain models can be at the heart of this language. The common language is the common language (Ubiquitous Language) throughout the team's work. Ubiquitous Language's glossary includes the class name and the primary action. The relationship between models becomes a combination of rules that all languages have. The meanings of words and phrases reflect the semantics of the model. Terms and rules, large scale structure, contextmap knowledge digestion –> model perfect –> term meaning change or new term increaseUse the model as the center of gravity of the language to ensure that the team adheres to the language in all communication activities. Drawing, writing, speaking ... there is a need to solve the problem of terminology confusion and ambiguous inconsistencies. Ubiquitous language transmits knowledge in a dynamic form. one of the best ways to model the essence is to study it through dialogue, identify possible model changes, and say multiple ideas about him. It is easy to be heard in such imperfect places. The model needs to be combined when discussing the system. Use the elements of the model and the interactions between the elements in the model to describe the scene aloud, and to combine the various concepts in a way that the model allows. Find a simpler way to express what you want to say, and then apply these new ideas to the diagram and code. UML is sometimes too detailed, sometimes many omissions. Figure is a means of communication and interpretation. (Simple small picture can be very good to achieve this goal) graphs and documents can lead people to focus on the core points. The usual practice is to chart the main, supplemented by text annotations. And I prefer to text-based, add a carefully selected simplified diagram as a comment. It is important to remember that the model is not a diagram. The purpose of the diagram is to help express and interpret the model. (Code can act as a repository for design details, and clear code has the same expressive power as UML.) )Documentation is just a supplement to the Code and verbal communication. But the code as a design document, itself also has limitations. He can drown out the details of the person who reads the code. The document should not repeat the content that the code has explicitly expressed. The implications should be highlighted in order to enable people to gain an in-depth understanding of the large-scale structure and focus on the core elements. Ubiquitous language can make documents more concise and clear.
When the domain model reflects the knowledge most relevant to the business, the requirements of the application become internal to the model and ubiquitous language can be used to describe such a scenario directly related to Model-driven design. The result is that documents such as specifications are written more simply, t because they don't have to convey the business knowledge behind the model. by minimizing the document and using it primarily to supplement the Code and verbal communication, you can avoid the document from being disconnected from the project. Select documents that need to stay up-to-date and interact closely with project activities, based on ubiquitous language and its evolution. XP relies entirely on executable code and code testing. However, the method name can be ambiguous, misleading or because it is outdated and cannot represent the essential meaning of the method. Eliminating ambiguity is declarative design. To keep the message of the code consistent with his behavior and intentions, there must be strict design procedures and a specific way of thinking. The explanatory model is not equal to the object model (technical model).
The technical model must be rigorously streamlined to achieve its functionality with minimal models.
Explanatory models can introduce other views, tools, and so on, just as a teaching tool for passing general domain knowledge.