Hello everyone, MY name is Bago. I have learned some knowledge about domain-driven design this week. I have made a lot of notes to share with you.

During daily requirements discussions, it is common to encounter a requirements meeting that has lasted more than an hour without reaching a consensus. As the business side (domain expert) clearly expressed, but the developers have never understood, the obvious reason is that the two sides do not have the same knowledge system, there is not a mutually understood language.

Language Gap

Although domain experts have limited knowledge of the technology of software development, they are familiar with the use of their domain terminology — possibly in a variety of styles. On the other hand, developers may understand and discuss systems in descriptive, functional terms that do not convey the meaning of domain expert language.

Developers may create abstractions to support the design, but domain experts cannot understand these abstractions. Developers working on different parts may develop different design concepts and ways of describing the domain.

Because of the language gap, domain experts can only describe vaguely what they want. Developers struggle to understand an area they are unfamiliar with, but can only form a vague understanding.

While a few team members will master both languages with skill, they will become bottlenecks in the flow of information, and their translations will be inaccurate.

Mutual translation confuses models

On a project without a common language, developers have to translate for domain experts. Domain experts act as translators between developers and other domain experts.

These translations confuse model concepts, which can lead to harmful code refactoring. This indirect communication masks the formation of a split — different team members using different terms without even knowing it.

Because the pieces of software do not fit together, this makes it impossible to develop reliable software. Translation leads to a failure to combine all kinds of knowledge and ideas that promote deeper understanding.

The consequences of different languages

If the language is fragmented, the project is bound to run into serious problems. Domain experts use their own terminology, while the language used by the technical team is adapted to discuss the domain from a design perspective.

The terminology used in the daily discussion is not consistent with the terminology used in the code. Even when the same person speaks and writes in different languages, the result is that deep representations of the domain are often too fleeting to be recorded in code or documentation.

Translation impedes communication and weakens knowledge digestion. However, neither language can be a common language because they cannot meet all the needs.

Make the domain model a common language

All the overhead of the program, with the risk of misunderstanding, was simply too high. Projects need a common language that is much more robust than the lowest common denominator of all languages. With a concerted team effort, the domain model can be the core of this common language, while closely linking team communication to software implementation. ** The language will be present in every aspect of the team’s work.

Lowest common denominator: the least common multiple of two denominators. For example, if the least common multiple of 2 and 3 is 6, then the lowest common denominator is 6.

Words of the common language

The vocabulary of the common language includes the names of classes and major operations. Some of the terms in the language are used to discuss the explicit rules of the model, and some are derived from the high-level organizational principles imposed on the model such as bounded contexts and context mapping diagrams.

Model-based language

Developers should use model-based languages to describe the artifacts, tasks, and functions in the system. This model should provide a language for developers and domain experts to communicate with each other, and domain experts should also use this language to discuss requirements, development plans, and features. The more commonly the language is used, the more smoothly understanding proceeds.

Model as the backbone of the language. Make sure the team sticks to this language for all internal communication and code, as well as for drawing, writing, and especially speaking.

Domain experts should resist terminology or structures that are inappropriate or do not adequately express the domain’s understanding, and developers should keep an eye out for ambiguities and inconsistencies that can hinder the design.

conclusion

In the WORLD of DDD, both domain professionals and developers should discuss business in a language that both sides understand. Although the language is difficult to understand in the beginning, it will get better as the project progresses.

In fact, it is not enough to have a universal language. Oral communication is easy to cause the loss of knowledge, which is not conducive to the future development of the project. The model should be established, all discussions should be model-based, and any changes should be reflected in the model.

recommended

  • Share a Family Financial System (source code attached)
  • Recommend a set of open source general background management system (attached source code)
  • Recommend a cool monitoring system
  • Got 20 actual combat projects from my friends, quick leader!
  • Recommend a perfect parking management system, Internet of things project Springboot, attached source code
  • Recommend an Internet enterprise level open source payment system
  • A fairy to private work software, hanging to no!
  • Recommend 10 super practical enterprise open source applications!
  • Open platform SDK design practice!
  • “Taobao” open platform interface design ideas
  • Nine classic design patterns in Spring