DDD统一语言
统一语言，最早听到这个概念是在学习DDD的时候。
统一语言在DDD中，是一个很重要的概念。
DDD中的几个大词：问题域，解决域，战略，战术，统一语言，界限上下文
对于网上的这个版本，我不太认同，把图修改一下：
因为统一语言是贯穿整个过程的，不仅要有战略高度，也得有具体战术措施。
在实践DDD的过程中，虽然明白统一语言重要性，但似乎更多的还是关注在编码实施。
引起的行为大致包含：
•技术人员使用业务人员的用语作为开发词汇•技术人员要将这些词汇映射到代码实现中•业务词汇整理出来，并随着项目发展一点点修正扩展
希望能达到代码既模型，代码既文档。主要还是为了代码。
通过这些理论的学习，至少可以规避一些问题：
1、销售订单上可不可以增加是否投诉字段？从客服角度，必须要加上，你作为系统设计者同意这个需求吗？
2、变更了profile上的买家地址，销售订单上的买家地址怎么也跟着变化了？
知识消化
然而，在《领域驱动设计模式的收益与挑战》[1]中提到，其实代码是次要的，DDD中更核心的是知识消化。
1、业务方与技术方沟通业务需求，在交流中，对部分业务知识达到共识，这部分交流语言被标准化为统一语言；
2、在不断地交流中，对于双方达成共识部分，凝炼成到模型中，对模型review，以确定描述了业务实际情况，发现缺乏或不适当概念时，进行修正，指取新的统一语言；
3、当模型确认后，以模型为样本，使用代码实现它；
4、上面是正向流程，技术方在重构代码时，也会同步修改模型，进来提取出新的统一语言，反哺业务方。
5、通过正逆流程，达到修改统一语言就是修改模型，修改模型也就是修改代码；修改代码也是修改模型，修改模型也相继修改统一语言。
6、这样打破了知识壁垒，给予业务方与技术方一种更好的协同方式。这就是DDD的精髓。让分析模型与实现模型融合了，不再像以前的方法一样分裂。
架构统一语义
统一语言的认知似乎就这么多了，有没有更高层次的洞见呢？最近学习了《郭东白的架构课》，发现统一语言还真没那么简单。
正如上面所说，之前更多的还是停留在编码实施层面。虽然整个项目参与方很多，但因为认知层次低，所以眼中只看到了产品经理和研发，因此统一语言的使用范围也被局限在了一个很小的规范内。
而把视野提升到一个大型项目的架构师角度。统一语言有了更高的价值。
郭东白讲不是统一语言，应该称为统一语义。我们要的是在语义环境中统一，而不单单是语言环境。
以实践DDD的经验，可以理解为人的语言和计算机语言的维度，并且语义是相同的。因为希望代码即模型，代码即文档。项目参与者交流的都得体现在代码中。所以姑且称为统一语言涵盖语言和语义，不纠结两者的称谓统一。
站到整个架构活动的层次上，项目的参与者就不仅仅是产品经理和程序员。事项也只是把代码写好。统一语言也不止存在于需求、模型、代码。
从整个项目视角看待，架构师需要拉通所有参与者：业务方，主要执行者，其他参与者，时刻对齐目标。让所有人的信息通畅，协作高效。
1、架构活动的目标，能够清晰传递并分解给每个参与者；
2、所有参与者的诉求，能够被准确地表达、记录和传递；
3、架构活动的目标和所有需求，能够反映到整体的架构规划中，并且能够被无损地拆分到多个子领域的任务中；
4、需求方能得到执行者的真实反馈，从而对整个架构活动的产出有个合理的期望；
5、每个子领域交付并组装好之后，能够语义契合、相互兼容，最终符合思想史活动的整体目标。
结合上面的知识消化过程，整合后，如下图所示：
为什么会有语义的分歧？
1、语境不同
如上面提到的为什么销售订单上不能增加投诉字段
2、认知不同
一种事物，从一个人的思维中，到表达出来，再由另一个人通过表达理解，并融入到自己的思维中，常常是有损的。
所以在一个大型的架构活动中，团队内部都会有理解偏差，更何况跨团队，跨业务。
如何消除语义分歧？
1、发现不同的语境
2、定义概念
上面知识消化图中，有一个方块叫统一语言提案，原因在于不是某个人直接定义一个语义，让所有人遵循。而是群策群力，深度思考和不断探索的过程。
3、语义建模
通过第2步定义概念，需要把不同概念引入到同一个语境中，也就是将两个不同的语境进行合并。
如上面的销售订单，指的是售中阶段的订单，而非售后阶段，所以不能增加是否投诉字段。
4、反馈修正
如第2步一样，自己的认知通常是存在于自己语境中的认知，要与所有人重新确认并多次调整，才能找到基本正确的统一语境。
5、公布、维护和使用统一的语境
不断使用和打磨实体定义，为企业带来统一语境。从自然语言到需求描述、到域模型定义过程，延伸到接口定义、模块设计、代码实现等等。
总结
最后简单总结一下：
站高一个层级，提升一个维度，同样的内容就看出的更丰富的内涵。
从一个兼职架构师提高到大型跨域项目的全职架构师，就不再是产品经理与研发之前围绕着需求的沟通，而应该再往前看，产品经理的前面还有真正的业务方，整个架构的目标。
使整个项目所有参与者的需求能够无损地表达、记录和传递。促使项目整体架构在一个逻辑完备和语义一致的环境中，确认整个架构的完整性，提升项目的成功率。
References
[1] 《领域驱动设计模式的收益与挑战》: https://www.zhuxingsheng.com/blog/benefits-and-challenges-of-domain-driven-design-patterns.html
