What is domain-driven design (domain driven)?

This article is from what is Domain driven Design? This article has been translated.

　　”... In many areas, the role of experts is reflected in their expertise rather than intellectually. “

-- Don Reinertsen

Domain driven design is a software development approach that enables software systems to be implemented accurately based on modeling real business processes and adapting to real business processes.

Traditional development work tends to be a technology-led process, where demand is passed from the business to the development team, and the developer creates the most likely scenario based on the description of the requirement.

During the waterfall development process, this leads to a large number of requirements documents that require frequent proofreading, analysis, review and approval. These documents are then handed over to the development team to become able to run the software.

The agile development approach can also incorporate requirements documents generated during waterfall mode, but agile methods will divide them into small tasks and "stories" during the actual process, and the subsequent development work will be based on the sort of tasks.

Domain-driven design largely allows you to pull out of these two disparate outcomes, allowing you to see how demand is being collected at the first scene--if you want to, it makes up for the way you do it first and the way you do it at the last minute.

Domain-driven design means that requirements are never "done", and demand is like a living document. More importantly, the live documents that remain to be discussed are actually the software itself--all documents are an image of the program code, a demonstration.

With the development and development of software systems, you will have a deeper understanding of a variety of issues--domain driven design is to find solutions to problems by understanding them in depth.

The real difference in domain-driven design, however, is that it treats software systems as a innuendo of business processes, and makes them dynamic, not driven. Domain-driven design is about getting you into the business process, understanding business terminology and practice methods. The technical aspects were placed in the second place, only the final means.

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

Domain experts are the second most important part of domain-driven design-people who can have a deep understanding of the field, including the business itself. These people constitute a necessary part of the development process. They may not need the "all-weather" job as traditional product owners in some agile development approaches, but they have to be constantly exposed and ready to participate in the development process. Domain experts cannot be used as outsiders, but as the core of the domain-driven design process-they are very much like a part of the development team, just like regular developers and testers.

Domain-driven design does not start and end-it is a continuous process of re-evaluating, re-constructing, modeling, and re-designing-every conversation will give you a further understanding of the problem. Domain-driven design has no "finish" point-it's always going on, ubiquitous language will evolve and grow, the domain model changes as the business understanding changes, the code is constantly re-organized and reconstructed to better express your understanding.

A variety of simulation products are produced and discarded, and the only real meaningful is the code. It is the only expression of the solution and is an expression that is no longer abstract. Documents are used to explain and describe the system, and only code can do this without losing points. That said, in a domain-driven design, the code must be high-quality, clear, expressive, without technical omission and terminology, as much as possible to make the code useful to the domain expert when it is interpreted.

Domain-driven design has no elaborate code, no fancy process, or "You don't need to know" modules. Domain experts don't need to be developers to understand what a key part of a software system is used to do these things. They also don't need to think about databases or batch tasks or other technology-related aspects.

Domain-driven design is the ultimate expression of agile methods-it is used to deal with changing and evolving needs-as anyone who has never been involved in a software project knows that the need for a project to remain static from start to finish is extremely rare, and in most cases it changes as the business grows and changes.

Through constant communication, domain-driven design guides you to express your business processes with the most accurate software.

What is domain-driven design (domain driven)?