通用语言

通用语言（Ubiquitous language）是指在软件设计中，业务人员和开发人员需要使用无歧义的统一语言来对话。

统一语言的重要性

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

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

如何提炼通用语言

在事件风暴的过程中，领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事。事件风暴也是一个项目团队统一语言的过程。

通过用户故事分析会形成一个个的领域对象，这些领域对象对应领域模型的业务对象，每一个业务对象和领域对象都有通用的名词术语，并且一一映射。

微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。

如何管理通用语言

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

对于统一语言，我建议每个项目都要有一份自己的核心领域词汇表。这个词汇表至少要包含中文、英文、缩写、解释四列，中文是我们日常交流和文档中经常要体现的，所以需要统一，这样我们在交流的时候才能高效，没有歧义；英文和英文缩写主要体现在我们的设计和代码上，也就是说我们的“统一语言”不仅仅是停留在交流和文档中，还要和代码保持一致，这样才能做到知行合一，提升代码的可读性和系统的可理解性。

比如一个CRM系统，我们可以从业务需求中挖掘出一些重要的领域概念，把这些概念整理成词汇表会如下所示。

有了这个核心领域词汇表，以后团队的交流、文档、设计和代码都应该以这个词汇表为准，这里需要注意的是，词汇表中英文对中文的翻译不一定非常“准确”，不过没关系，语言就是一个符号，共识即正确，只要大家容易理解达成一致即可。就像上面词汇表中私海这个概念的翻译是Private Sea，这是一个典型的Chinglish，正统的翻译是Territory，但是大家都认为Private Sea更容易理解，只要达成共识，用这个名称也挺好。

坚持使用通用语言

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

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

1. 暴露对于业务领域不一致的理解，并最终形成统一。通用语言所包含的术语、概念，体现了业务专家和开发人员对于业务领域的认识，坚持使用通用语言有助于大家交互认识，形成统一。
2. 在讨论中修正对于业务领域不完善的理解，从而完善业务模型。我们经常在与其他人的交流中迸发出新的想法，而这些新的想法正是由于双方交换认识促成的。
3. 使业务模型与软件代码保持同步。假设业务专家只在业务模型的设计时采用专业的术语，而在日常沟通过程中为了方便其他人理解采用其他的语言描述，那么开发人员可能产生不同的理解，从而导致业务专家设计出来的模型与开发人员所编写的代码逐渐偏离。
4. 持续的传递知识，使知识保持双向同步。我们在前面已经讨论过，软件设计整个过程都是知识的加工过程，不仅在需求分析时存在密集的业务领域知识，开发人员在做程序设计甚至编写代码是也可能产生新的知识，只有在业务专家和开发人员的沟通过程中，坚持使用通用语言进行沟通，才能高效地彼此分享知识，保持同步。
5. 迫使业务专家和开发人员共同参与建模过程。如前面所说，业务模型是浓缩的、结构化的真实业务领域的反映。业务模型中包含着大量的通用语言，在沟通过程中坚持使用通用语言，并进行调整、修正，这些内容最终将体现到模型当中。从而，业务和开发能够共同参与建模，使模型更加完善。