Reprinted from: https://cloud.tencent.com/developer/article/2011322
Author: Pan Jiayu (WeChat public account UMLChina)
(2) The "universal language" caters to the need to stay in the comfort zone
So, why does the DDD circle reinvent the "universal language" and tout it strongly?
The reason is explained in <u style="box-sizing: border-box; list-style: inherit;">8.1.8.3 Why Pseudo-Innovation is Popular</u> : it caters to the "mass developers" who stay comfortably district needs.
We emphasized above that modelers must learn domain knowledge with an open mind, and this is a very hard job, and many people are unwilling to suffer from it.
The beauty of "universal language" is that it tells you that you don't have to endure hardships or get out of your comfort zone!
Let's first look at Eric Evans' statement of "universal language" in "Domain Driven Design", as shown in Figure 8-57.
From Figure 8-57, we can see that the "universal language" is the intersection of "technical terminology" and "business terminology", in the words of this book, it is the intersection of "non-core domain terminology" and "core domain terminology".
The question is, is there an intersection?
Technical terms (non-core domain terminology), such as browser-related terms: request, response, rendering, DOM, serialization, deserialization...
Business terms (core domain terms), such as shopping mall-related terms: commodity, customer, order, inventory, cashier, inventory...
Where do "technical terms" and "business terms" intersect? Could it be that these orthogonal terms are randomly combined to achieve the effect of nonsense brushing workload? Here we can recall our statement about a×b×c in <u style="box-sizing: border-box; list-style: inherit;">8.1.3 Mapping and collaboration between domains</u> .
The so-called "technical terms" in DDD discourse have nothing to do with "technology" at all. In fact, they are just "business terms" fabricated by "technical staff" without humbly learning domain knowledge-"business terms fabricated by technical staff".
And the "universal language" makes it justifiable for "technical people" to make up "business terms", which is a big step backwards.
In reality, it is inevitable that there will be "technical personnel" who are too lazy to investigate stakeholders, too lazy to learn domain knowledge, and do things indiscriminately. This is due to human nature, and it is difficult to eliminate it, but at least we still know that it is not good to do so, and what should be done if we want to do better.
If you turn laziness into righteousness, the taste will change.
Just like when we say "people are selfish", this is a low-key description of a fact, but if we say with confidence that "people are not for themselves, heaven and earth will destroy them", the taste will be different.
Figure 8-58 is a statement by Vaughn Vernon in "Implementing Domain-Driven Design":
Look, it's not business language, it's not Industry Standard (Industry Standard, better translated as industry standard) terminology, it's created by the team itself. That is to say, in the same field, different development teams and different people in the team may get different "universal languages".
Observations will affect the results. Is this the "Schrödinger's cat" of software development? You have your physics, I have mine, the development team has its own "team sentiment", and the "technicians" have such a comfortable life!
Even better, "technicians" can also touch themselves. Originally, I was a high-level "technical", but now I have opened an opening for your "business" to let you participate. Your "business" should be grateful to Dade!
This is the arrogance brought about by a sense of superiority in intelligence (of course, there are also money and power, which are inconvenient to expand, so I won’t mention them).
如果某个领域的从业人员的平均智力水平(学历、学校、智商等)不如软件开发行业，那么软件开发人员，即所谓的“技术人员”在面对该领域的“业务人员”时，是有一种优越感的。
这种优越感让“技术人员”在做供应链系统、商场系统时有足够的底气来编造“通用语言”，因为他觉得货车司机、仓管、外卖小哥、商场经理的智力水平不如他。
如果所开发系统的核心域是凝聚态物理、非线性分析之类的，“技术人员”面对智力水平超过他的“业务人员”，这份优越感就不会有了。这时，“技术人员”可能就会虚心去学习相关领域知识，因为他觉得这是一件高大上的事情，有面子！
(3)不要让利益博弈压倒“客观规律”。
有一种论调值得警惕。该论调认为“通用语言”让“技术人员”一方有了话语权，不用受“业务人员”一方主导，不用低三下四地去学习领域知识，这对“技术人员”一方有好处。
这样的论调是利益博弈压倒了领域的“客观规律”，不可取。
如果系统的核心域模型没有准确体现领域的“客观规律”，而是发生较大的偏离，那么最终的结果必然是该系统容易出错或者应变成本很高。这种情况也许对某些摸鱼的开发人员有“多劳多得”的好处，但对于整个开发团队以及涉众来说，肯定是有害的。
注意，上面说的“客观规律”加了引号，意思只是说，这些规律不会受开发团队、实现技术等变化的影响，不代表这些规律符合科学。
最常见的，游戏中的知识体系和各种规律，像王者荣耀中的攻击、防御、移动，是魔法不是科学，但建模人员依然要认真去学习和体会这一套体系中的各种“学问”。
同理，上文提到，建模技能可以帮助清理术语中的冗余和矛盾，但仅止于此，建模技能并不能帮助判断该领域的知识是否科学。
(4)“语言”过于宏大
“通用语言”的“语言(Language)”这个词太大。语言要有自己的语法，汉语算，C算，UML也算，“通用语言”哪里有？术语集或术语表的称呼更合适。