What is domain driven design )?

This article is from what is domain driven design? This article is translated.

　　"... In many fields, the role of experts is embodied in their professional knowledge rather than intelligence. "

--Don reinertsen

Domain driven design is a software development method, the purpose is to allow the software system to accurately model and adjust the real business process based on the actual business process.

Traditional development tends to be a technology-oriented process. The requirements are transferred from the business side to the development team. developers create the most possible assumptions based on the requirements.

In the process of waterfall development, this leads to a large number of requirements documents that require frequent verification, analysis, review, and approval. Then these documents are handed over to the development team to become software that can run.

Agile development methods can also adopt the requirement documents generated during the waterfall model process, but Agile Methods divide them into small tasks and "Stories" in actual processing ", subsequent development work will be sorted based on these tasks.

The field-driven design allows you to draw from these two completely different results, allowing you to see how needs are collected at the first site-if you want to see, it makes up for the difference between the method used first and the method used in the last minute.

The domain-driven design method knows that the requirement will never be "completed", and the requirement is like a live document. More importantly, these active documents to be discussed are actually the software itself-all documents are an image of program code, a demo.

With the development and development of software systems, you will have a deeper understanding of various problems-Domain-driven design is to find a solution to the problem through in-depth understanding.

However, the real difference between a domain-driven design is that it uses a software system as a reflection of a business process and enables, rather than drives, the software system. Domain-driven design requires you to go deep into the business process and understand the business terms and practices. The technical aspects have been put at the second place, but it is only a final means.

Ubiquitous language (UL) is the center of domain-driven design-a common and growing language. It is a language derived from business terms and negotiated by the development team. If a business person does not understand a term in UL, UL may need to improve development. If a technician does not know a term in UL, it may be that they need to communicate with field experts.

Domain experts are the second most important part of the field-driven design-these people have a deep understanding of this field, including the business itself. These members constitute necessary components in the development process. They may not need to work around the clock as traditional product owners in some agile development methods, but they must be continuously exposed during the development process, and be ready to participate in the development process at any time. Domain experts cannot be treated as outsiders, but as the core of a domain-driven design process-they are very much like a part of a development team, just like common developers and testers.

The field-driven design has not started or ended-it is an ongoing re-evaluation, re-reconstruction, and re-modeling, re-design the continuous process-each conversation will give you a better understanding of the problem. The field-driven design is not "completed"-it is always in progress; the ubiquitous language will continue to develop and grow, and the domain model will change with the change in business understanding, code is constantly re-organized and restructured to better express your understanding.

Various simulation products are generated and discarded, and the only truly meaningful thing is code. It is the only expression of the solution and a non-abstract expression. The document is used to explain and describe the system, and only the code can achieve this without losing points. This means that in the field-driven design, the Code must be of high quality, clear, expressive, and technically omitted or specialized terms, try to make the code meaningful to domain experts when being interpreted.

There is no elaborate code in the field-driven design, and there is no peculiar processing process, or a module that "You don't need to know. Domain experts do not need to be developers to understand what is the key part of a software system for doing this. They also do not need to consider database or batch processing tasks or other technical-related aspects.

Domain-driven design is the ultimate expression of Agile Methods-it is used to handle changing and evolving needs-as anyone who has never been involved in software projects knows-the needs of a project from the beginning it is extremely rare to keep the end unchanged, in most cases, it will change with business growth and changes.

Through continuous communication, the domain-driven design will guide you to express your business processes with the most accurate software.