本节书摘来自异步社区《领域驱动设计：软件核心复杂性应对之道（修订版）》一书中的第2章，第2.3节一个团队，一种语言，作者【美】埃里克•埃文斯（Eric Evans）, 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.3　一个团队，一种语言

技术人员通常认为业务专家最好不要接触领域模型，他们认为：

“领域模型对他们来说太抽象了。”

“他们不理解对象。”

32

“这样我们就不得不用他们的术语来收集需求。”

上面只列举了我从一个使用两种语言的团队中听到的少数几个原因。忘掉它们吧。

当然，设计中有一些技术组件与领域专家无关，但模型的核心最好让他们参与。过于抽象？那你怎么知道抽象是否合理？你是否像他们一样深入理解领域？有时，某些特定需求是从底层用户那里收集的，他们在描述这些需求时可能会用到一小部分更具体的术语，但领域专家应该能够更深入地思考他们所从事的领域。如果连经验丰富的领域专家都不能理解模型，那么模型一定出了什么问题。

最初，当用户讨论系统尚未建模的未来功能时，他们没有模型可供使用。但当他们开始与开发人员一起仔细讨论这些新想法时，探索共享模型的过程就开始了。最初的模型可能很笨拙且不完整，但会逐渐精化。随着新语言的演进，领域专家必须付出更多努力来适应它，并更新那些仍然很重要的旧文档。

当领域专家使用这种语言互相讨论，或者与开发人员进行讨论时，很快就会发现模型中哪些地方不符合他们的需要，甚至是错误的。另一方面，模型语言的精确性也会促使领域专家（在开发人员的帮助下）发现他们想法中的矛盾和含糊之处。

开发人员和领域专家可以通过一步一步地使用模型对象来走查场景，从而对模型进行非正式的测试。每次讨论都是开发人员和专家一起使用模型的机会，在这个过程中，他们可以加深彼此的理解，并对概念进行精化。

领域专家可以使用模型语言来编写用例，甚至可以直接利用模型来具体说明验收测试。

有时，有人会反对使用模型语言来收集需求。毕竟，难道需求不应该独立于实现它们的设计吗？这种观点忽视了所有语言都要基于某种模型这一事实。词的意义是不明确。领域模型通常是从领域专家自己的术语中推导出来的，但已经经过了“清理”，以便具有更明确、更严密的定义。当然，如果这些定义与领域公认的意义有较大差别，领域专家应该反对。在敏捷过程中，需求是随着项目的前进而演变的，因为几乎不存在现成的知识可以充分说明一个应用程序。用精化后的Ubiquitous Language来重新组织需求应该是这种演变过程的一部分。

33

语言的多样性通常是必要的，但领域专家与开发人员之间不应该有语言上的分歧（第12章将讨论多个模型在同一个项目上共存的情况）。

当然，开发人员的确会使用领域专家无法理解的技术术语。开发人员有其所需的大量术语来讨论系统技术。几乎可以肯定的是，用户也会用开发人员无法理解的、超出应用程序范畴的专用术语。这些都是对语言的扩展。但在这些语言扩展中，同一领域的相同词汇不应该反映不同的模型。

34 有了Ubiquitous Language之后，开发人员之间的对话、领域专家之间的讨论以及代码本身所表达的内容都基于同一种语言，都来自于一个共享的领域模型。