统一语言为什么不能统一(四)

一、背景

前面几篇已经从各个方面说统一语言不能统一的一些原因，但是我们终究希望让统一语言可以在团队中达成一些共识，并让统一语言在沟通，代码和应用上面提供一些帮助。本文将是统一语言的最后一篇文章，将重点探讨统一语言有可能统一的一些方法。文末也有整理关于本系列的完整思维导图，需要的话可以收藏。

二、统一的最大价值

可能因为统一语言在应用中变得非常困难，但是我们仍然不能忽略他的价值，所以这里重新强调一下。

2.1 沟通表达

首先当我们没有记录统一语言概念的情况下我们可以在沟通表达上面形成共识，达成统一对齐。

2.2 控制复杂度

为什么要探索这个统一语言这个维度呢，因为我们终究希望从现实中找到一些关键信息或者线索模型来在程序中映射现实模型。最终我们的目的是通过程序来帮助完成现实业务，但是我们不希望程序变得过度复杂，这可能会让本非常简单的事情变得异常糟糕。

三、统一的几种方法

3.1 刻意对齐沟通

就目前而言学习DDD的大多数人可能技术基因会强一点，但是统一语言需要让团队达成一个共识，所以比较关键的地方是产品和领域专家来帮忙对其这一部分，不曲解不包装的来表达整个业务流程和业务需求，不然关于一些业务语意到了开发这里会很容易变味，所以有时候我也会发一生感慨：产品经理应该看看DDD。

3.2 数据代码文档沉淀

大多数情况下第一步做的并不是很好，毕竟客观现实是比较割裂的，因为职责角色的问题在进行领域建模功能实现和文档相关积累的时候只能站在某一视角去争论，这样的话可能会让统一语言的沉淀也变得相对割裂，比较好的一些实践是工程化实践，可以采用的一些方法如下：

1. 在代码层面上使用统一语言术语来帮助构建真正的业务场景，同时让统一语言的简单概念形成doc文档跟着工程模块走
2. 有些统一语言在落地到建模的时候会被识别为值对象和业务配置类对象，这些看着不是很起眼，但是是统一语言的一个关键地方，所以这些地方的变化自然而然的会引起整个业务流程的统一语言发送变化，所以这一部分也建议在工程文档中予以体现和管理
3. 统一语言模型和业务文档不跟着组织和人走。这个可能大多数企业基本都不会这么干，我的意思是某些业务领域一旦被识别到比较重要的话那么整个领域应该就需要建立一个文档库，所有相关的接口，模型，技术方案都应该在这个文档库里面。而从部门或者人主管理解和运用的情况下可能会因为安全或者管理方式的变化会让统一语言散落在各个文档库各个系统文档需求里面。比如存在交接的情况，存在空降领导的情况，存在业务重组等等。

3.3 寻找专业文档并引用

在某些业务中我们可能并不需要造词或者重新跟领域专家来对新的统一语言，有时候一些友商的文档或者专业的文档会给一些帮助。我们可以站在巨人的肩膀上来重新构建一些更符合自己业务场景的统一语言列表。

3.4 寻找领域专家释意

有时候我们在寻求理解某些业务场景或者业务现象的时候无法从网上或者专业文档上寻找答案，那这时候就需要寻找领域专家了，通过领域专家我们可能会得到一些更合适的答案，并帮助完善统一语言体系，当然需要注意的是这些答案仍然需要维护在一个相对统一的地方。

3.5 持续回顾

现在我们从统一语言的实效性来看一下如何管理统一语言。当我们构建好统一语言的时候就注定了会产生一个统一语言的生命周期，有些新的统一语言加入进来有些则需要被淘汰。但是客观情况下我们很难主动的去淘汰一些统一语言，而新加入的统一语言又可能在另外的文档里。所以在达成管理维护的共识的情况下，相关产品和开发需要主动持续回顾在自己所负责的业务领域中有哪些统一语言会随着业务的消失而热度下降，同时需要慢慢淘汰掉或者从自己领域的统一语言中剥离出来。
持续回顾可以让统一语言跟着业务和工程走，即使不维护了，或者方向变了，那么统一语言仍然可以像代码一样慢慢迭代。终究可以从中得到一些好处。

3.6 控制统一语言的本质复杂性

上面的一些实践性方法可以帮助我们发挥一些统一语言的价值。但是我们需要注意到。有些统一语言在开发或者测试眼力懂得一些概念只是暂时的，他们更希望关系业务流程是怎么走的，支持哪些场景，有哪些变化等等。所以在构建统一语言的时候我们需要控制一下统一语言的本质复杂性，比如语言之间的业务关系，哪些角色参与了业务流程，这些业务流程在时序图文档上是怎么应用统一语言的。

3.7 统一语言配置化&结构化

最后提一个比较中肯而且可以尝试实践的话题，就是让统一语言用DSL的方式来描述，同时我们需要结合一些其他工具文档来从统一语言的角度阐述业务。当然现实情况是代码和工程文档(需求文档,技术文档)是分开的，所以这里需要构建一个相对完善的统一语言配置管理平台来链接业务上的统一语言和技术上相关的文档。
很多javaer开发者都知道有apollo或者nacos实现分布式配置，关于技术的和业务的都可以在上面进行维护，但是我们可能需要从整个产品工程上去考虑这个事情，当然我认为俩者具有重合的部分，关注点不太一样。因为这些业务配置在配置中心系统里就失去了统一语言的一些原貌，而统一语言配置管理平台需要链接每个业务系统里的业务配置，统一语言和工程文档相关的东西。

四、统一语言配置管理平台

4.1 工程效能&研发效率平台

几乎每个能叫得上名字的互联网公司都会或多或少的涉及到这两个平台，这两个平台从软件研发的角度构建了一些统一语言并将之工具化和流程化，比如构建一些维度和指标来体现产研交付能力。

4.2 confluence&语雀&PRD

从业务上讲很少有业务能够像工程效能和研发效率平台那样建设完成之后会相当于基础服务一样变得相对稳定，所以这里从文档上来讲最多变化的就是一些文档管理工具。这些文档管理工具就目前看几本都大同小异，对统一语言的管理只是变得好了一点点。

4.3 产研大图或者商业能力地图

有时候我们很容易的去想复用一些东西，包括文档，接口和服务等等。但是大多数情况下我们很难找到一个企业内部可以复用的平台或者我们需要的一些服务能力，这些能力有人也会用产研大图或者商业能力地图来整理，但是由于管理范围太过宽泛，所以找起来或者建设起来仍然相对麻烦。

4.4 统一语言配置管理平台

这里我们看一下统一语言配置管理平台能否可以帮助结合上面的优点来实现业务和技术上对于统一语言的需求。这里简单列一下统一语言配置管理平台的需求

1. 对统一语言管理形成一套DSL方便业务接入和管理
2. 按照业务领域划分统一语言文档，配置，应用管理库(与其他平台相互打通)
3. 结合工程代码和工程技术需求和方案等文档(文档平台间相互打通)
4. 对相关业务领域的配置和统一语言概念做集中统一管理
5. 根据业务态势感知统一语言的实效性并做打标分析

五、总结

上面从一些相对可行的方法来尽可能的让统一语言形成自己的体系并对接不同的系统，同时借助整个团队的力量从不同方面来应用统一语言，并享受统一语言在不同业务领域给予的一些帮助，当然要想用好就要深入了解统一语言的方方面面。
关于《统一语言为什么不能统一》的话题到此结束，希望读者们有所收获。后面会有更多系列文章来说探讨DDD和架构思想等话题，敬请期待。