2. 通用语言

对通用语言的需要

通过前一章的案例，我们认识到由软件专家和领域专家通力合作开发出一个领域的模型是绝对需要的，但是，那种方法通常会由于一些基础交流的障碍而存在难点。开发人员满脑子都是类、方法、算法、模式，总是想将实际生活中的概念和程序工件做对应。他们希望看到要建立哪些对象类，要如何对对象类之间的关系建模。他们会按照继承、多态、面向对象的编程等方式去思考，会随时随地这样交谈，这对他们来说这太正常不过了，开发人员就是开发人员。

但是领域专家通常对这一无所知。他们对软件类库、框架、持久化甚至数据库没有什么概念。他们只了解他们特有的专业技能。

在空中交通监控样例中，领域专家知道飞机、路线、海拔、经度、纬度，知道飞机偏离了正常路线，知道飞机的发射。他们用他们自己的术语讨论这些事情，有时这对于外行来说很难直接理解。

为克服这种交流方式的不同，在建立模型时，我们必须通过沟通来交换对模型和模型中涉及到的元素的想法，应该如何连接它们，哪些是有关的，哪些不是？在这种层次上的交流对一个成功的项目而言是极为重要的。如果一个人说了什么事情，其他的人不能理解，或者更糟的是错误理解成其他事情，又有什么机会来保证项目成功呢？

当团队成员不能享用一个公共语言来讨论领域时，项目会面临严重的问题。领域专家使用自己的行话，技术团队成员在设计中也用自己的语言讨论领域。

代码可能是一个软件项目中最重要的产物，但每天用来讨论的术语却与代码中使用的术语脱节了。即使是同一个人都需要使用不同的语言来交谈和书写，所以要想完成对领域的深刻表达通常需要产生一种临时形式，但这种形式不会出现在代码甚至是书写的内容中。

在交流的过程中，需要做翻译才能让其他的人理解这些概念。开发人员可能会努力使用外行人的语言来解析一些设计模式，但这并不一定都能成功奏效。领域专家也可能会创建一种新的行话以努力表达他们的这些想法。在这个痛苦的交流过程中，这种类型的翻译并不能对知识的构建过程产生帮助。

在设计过程中，我们倾向于使用自己的方言，但是没有一种方言能成为一种通用的语言，因为它们都不能满足所有的需要。

在讨论模型和定义模型时，我们确实需要讲同一种语言。那么是哪种语言呢？开发人员的语言？领域专家的语言？介乎两者之间的语言？

领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。

使用模型作为语言的核心骨架。要求团队在进行所有的交流是都使用一致的语言，在代码中也是这样。在共享知识和推敲模型时，团队会使用演讲、文字和图形。这儿需要确保团队使用的语言在所有的交流形式中看上去都是一致的。因为这个原因，这种语言被称为“通用语言（Ubiquitous Language）”。

通用语言连接起设计中的所有的部分，建立了设计团队良好工作的前提。可能会花费数周乃至数月的时间才能让一个大规模项目的设计成型。团队成员会发现一些初始的概念是不正确的或者不合适宜，或者发现一些需要考虑并放进总体设计中的新的设计元素。没有了通用语言，所有的这一切都是不可能的。

这种语言的形成可不是一日之功，它需要做出艰苦卓绝的工作并关注很多方面的内容，才能确保语言的核心元素被发现。我们需要发现定义领域和模型的那些关键性概念，发现描述它们的相应的用词，并开始使用它们。它们当中的一些可能很容易被发现，但有些却不能。

通过尝试反映其他可选模型的其他的表述方式，可以消除这个难点。然后重构代码、重命名类、方法和模型以适应新的模型。使用我们能够正常理解的普通词汇，化解交谈所使用术语之间的混乱。

构建一个类似这样的语言会得到一个清晰的结果：模型和语言相互密切关联。一个对语言的变更会变成对模型的变更。

领域专家会反对用那些很笨拙的或者不适当的字眼或者结构来传达对领域的理解。如果领域专家不能理解模型或者语言中的某种内容，那么就如同是说这种内容存在某种错误。从另一方面讲，开发人员应该留意那些与他们试图呈现在设计中的内容存在二义性或者不一致的部分。

创建通用语言

我们应该如何开始去构建一种语言？看一个假想的软件开发人员和领域专家之间关于空中交通监控项目的对话吧。需要留意粗体的那些词。

开发人员：我们想监控空中交通，应该从哪里开始？

专家：

让我们从最基础的开始吧。所有的交通由飞机组成。每架飞机从一个出发点起飞，并在一个目的地点着陆。

开发人员：

很容易嘛。在飞行时，飞机会按照驾驶员的意愿选择任何空中线路吗？是不是等于说他们可以决定他们能走哪条路，只要他们能到达终点？

专家：

哦不。驾驶员会收到一条他们应该遵照的飞行路线。并且他们必须尽可能地跟那条飞行路线吻合。

开发人员：

我会把这条路线考虑成空中的 3D 线路。如果我们使用笛卡尔系统坐标，那么一条飞行路线会被简化成一系列 3D 的点。

专家：

我可不这么认为。