领域驱动设计 101 - 通用语言

在前面的讨论中提到，领域驱动设计强调在软件设计过程中构建出完善的业务模型，而业务模型可以看做是浓缩的、结构化的业务领域知识。模型不过是软件开发的中间产物，最终产物是面向用户的可用软件产品，这个最终的软件产品可以看作是现实当中业务领域在计算机世界中的存在形式。

统一语言的重要性

首先，我们必须承认沟通的重要性。没有沟通，我们不可能获得合作者的想法，团队协作无从谈起。没有沟通，知识将无法交换，最终独立的个体将陷入发展停滞。没有沟通，将会产生误解和分歧，如果任由发展可能将导致冲突...

而语言是沟通的媒介，就好像网络通信双方的协议，如果协议没有统一，通信将无法进行。根据前面的讨论，软件开发不过是利用软件开发技术对知识迁移的过程，从现实世界转化到计算机世界。软件开发过程必然需要不同角色的协作，从业务专家到分析设计人员到软件开发人员，他们都是整个知识加工、转化过程的参与者。那么，面对一个特定的业务领域，他们必然要首先统一对所面对的领域的认识，同时，在沟通的过程中他们要采用互相能够听懂的术语，只有这样才能高效沟通，最终形成无限接近于问题领域的实际可用的软件产品。

通用语言（Ubiquitous Language)

在 DDD 的理论中，将上述软件开发的参与者们在沟通过程中所采用的术语、概念、规则以及组织关系称为通用语言（Ubiquitous Language）。所谓通用语言，至少表达两个方面的含义：

1. 在参与者们所面对的问题领域中，他们所采用的这种语言对于相同的事物采用相同的描述、术语，沟通过程中无需翻译、也无需额外的学习成本。

2. 通用性仅仅在当前问题领域中保证，如果跨出当前的团队或者小组，通用性将无法保证。

那么，在软件开发设计过程中，通用语言包含哪些对象呢？

类：这里采用面向对象的术语。类即对现实世界中事物的抽象定义。当在分析设计阶段对某一个对象确定一个名称后，可以在开发阶段直接用作类名。但是需要注意，类的名字必须尽可能准确的反映事物的本质。例如，对于一个人编辑文章并发布的过程，这个人可能有如下称呼：作者、发文章者、业务、编辑、经办。很明显作者是最恰当的定义，他准确表达了编辑文章并发布文章这个过程，以及所产生的成果与这个人的关系，同时也不失简洁。

操作：即对现实对象可以执行的操作，对应于类的函数。

关系：关系表达的是模型中类之间的组织原则，不同对象之间的联系整体上构成了整个业务模型。

规则：规则限定了模型正常运转应当遵循的边界和限制。超出这些边界和限制，将会发生异常。

坚持使用通用语言

通用语言并不应该只是静静躺在需求文档中的若干术语解释或者概念，也并不应该是开发人员在开发程序时对程序中的类和方法所起的名字。通用语言之所以称为一个语言，其最大的价值在于在软件设计过程中，业务专家与开发人员之间沟通交流的媒介，通过在沟通交流过程中交换对业务领域的认知，反复修正最终达到对业务领域的统一认识，最终才能设计出贴合实际软件产品。

在软件设计过程中，业务专家和开发人员必须坚持使用通用语言。之所以坚持使用通用语言，有如下好处：

1. 暴露对于业务领域不一致的理解，并最终形成统一。通用语言所包含的术语、概念，体现了业务专家和开发人员对于业务领域的认识，坚持使用通用语言有助于大家交互认识，形成统一。

2. 在讨论中修正对于业务领域不完善的理解，从而完善业务模型。我们经常在与其他人的交流中迸发出新的想法，而这些新的想法正是由于双方交换认识促成的。

3. 使业务模型与软件代码保持同步。假设业务专家只在业务模型的设计时采用专业的术语，而在日常沟通过程中为了方便其他人理解采用其他的语言描述，那么开发人员可能产生不同的理解，从而导致业务专家设计出来的模型与开发人员所编写的代码逐渐偏离。

4. 持续的传递知识，使知识保持双向同步。我们在前面已经讨论过，软件设计整个过程都是知识的加工过程，不仅在需求分析时存在密集的业务领域知识，开发人员在做程序设计甚至编写代码是也可能产生新的知识，只有在业务专家和开发人员的沟通过程中，坚持使用通用语言进行沟通，才能高效地彼此分享知识，保持同步。

5. 迫使业务专家和开发人员共同参与建模过程。如前面所说，业务模型是浓缩的、结构化的真实业务领域的反映。业务模型中包含着大量的通用语言，在沟通过程中坚持使用通用语言，并进行调整、修正，这些内容最终将体现到模型当中。从而，业务和开发能够共同参与建模，使模型更加完善。

文档和图

通用语言仅仅停留在口头肯定不够。

文档和图是软件设计过程中常见的工具，对于有一定复杂度的业务领域，仅仅凭借口头讨论以及代码往往并不能软件设计过程中的知识有效地保留下来。文档和图除了记录和留存知识外，还是结构化组织知识的工具，在编制过程中，软件设计人员往往能够有新的发现。

在迭代式的敏捷开发中倡导低文档，这是因为繁杂的文档容易成为软件开发过程中的拖累，同时并不能产出超出其成本的价值。

那么，如何平衡使用文档和图工具带来的收益及其成本呢?

那些倡导低文档或者无文档的开发人员，其核心论点在于，软件的设计已经全部体现在了代码当中，因此文档和图是多此一举。但有过复杂或者稍大型应用软件开发经验的开发者都知道，当系统开始变大需要很多人同时维护，并且随着时间推移可能移交给后来的开发者时，没有像样的文档将多么痛苦。除了通常很难保证代码的整洁合理，代码本身在面向人类时的自我解释性远不如精心组织过的文档和图是其主要原因（毕竟代码是人类和机器沟通的语言）。

领域驱动设计倡导：采用互为补充的文档和图记录设计的框架和流程，而那些重要的细节则只需在代码中体现即可。

需要注意的是，文档和图毕竟不是软件系统的一部分，时刻与软件系统保持同步变得很困难（这也是很多低文档和无文档观点的论据之一）。因此，在软件设计中需要关注使文档和图保持新鲜，体现最新的设计内容。这可以通过几个方面来保证：一方面，如前所述，文档和图应该尽量保持简洁，只记录重要的框架、流程设计；另一方面，将文档和图的编写以及检查作为开发流程中的必需环节在开发纪律或者规约中进行明确。最后，文档和图应该时刻保持具有价值，将那些真正能够体现设计关键内容保留下来，删除那些无关紧要或者不再重要的内容。