Domain Driven design: The core complexity of software-2

2015-06-29 chapter II Language exchange and usage patterns: UBIQUITOUS LANGUAGE (Common language) development lies in the need to build a common language to reduce the cost of communication based on business, development and business consensus when developing domain experts To discuss the overture with a slang that both sides can understand the difference in terminology, the cost of communication and understanding, and the need to model it with a common terminology in order to reduce costs. The term is more about business than development, but development has a common understanding of the meaning and business of terminology. When a domain language describes a business scenario or builds a domain model, if there is ambiguity, a domain expert is required to clarify the developer, clear the ambiguity, and update the model. Common language includes verbal communication languages, charts, and documents. Written documentation is not required, but it can be used as a supplement to verbal communication, the documentation is based on the domain model, not the repetition of the code. If a written document is not updated in time, it loses its meaning, please file it. So the written document please keep as concise as possible the text and the diagram is complementary, do not deliberately biased to a certain description. The code is the most real-time and effective description of the model, but it is too biased and detailed, not to be fully understood by the domain experts, even if the domain experts can understand, but will be deep in the details. So documentation is required as a supplement. Diagram is not exactly a UML diagram, you can use a simple diagram to describe the business process, more applicable and communication. This chapter is more emphasis on the use of a mutual understanding of the language, words and graphs to describe the system, so that you can analyze and design the system.

Domain Driven design: The core complexity of software-2