实现领域驱动设计（2）- 交流与语言的使用

领域模型可以成为软件项目通用语言的核心。该模型是一组来自于人员头脑中的概念，一级反应了领域深层次
含义的术语和关系。
这种基于模型的交流并不局限与UML(统一建模语言)图，为了最有效的使用模型，需要充分利用各种交流手段，
基于模型的交流提高了书面文档的的效用。

---

一、通用语言

有经验的软件开发人员都会经历这样的事情，两个人在争论，但彼此说的确不是一件事，由于计算机是西方文明的产物，引入国内产生了很多翻译，加上每个人的理解不同导致沟通不畅，纯技术层的讨论如果有第三人在场或许可以很快结束这种沟通。但如果是新组建的团队去实现一个复杂的陌生业务，这种情况会变得更加频繁，低效率的沟通是所有人工作的敌人。
领域专家有自己的术语（业务人员），产品有自己的语言，开发有自己的理解。
这时候需要一个人牵头对开发过程中的业务术语进行统一管理
举一个反例：

大规模分布式系统中会有独立的用户中心，用户中心提供了用户注册、认证、鉴权等服务，业务系统会对的接统一的用户中心，对于用户中心的开发来说，商城的业务线负责电商业务，金融的业务线负责消费贷业务，当两个业务线协作完成消费贷流程时，三方的沟通就需要统一的语言，当电商的开发说：“用户没有留下地址”，金融的开发说：“用户在申请借款的时候已经填了地址”。

双发的沟通就会起波折。

UBIQUITOUS LANGUAGE的词汇包括类和主要的操作名称。语言使用的越普遍，理解进行的越顺畅。

通用语言在实现领域驱动中往往会被忽略，笔者经历的几个使用了领域驱动设计的项目，没有专门设置通用语言的环节，诚然当时的团队彼此熟悉，业务熟练，大家沟通起来仍会发生彼此认知不一致的情况。

对于新的团队，可以视情况，如果成员之间彼此磨合快，可以不必专门花费时间定义专业术语。

对于制定通用语言的划分，个人认为属于产品团队，从产品的需求提出便定义出通用的定义。
但遗憾的是，大部分产品经理没有意识这个问题，甚至很大一部分软件开发工作还是停留在口头需求，边做边改的状态，极大的影响团队的效率

二、 一个团队，一个语言

技术人员通产任务业务专家最好不要接触领域模型，
他们认为：
“领域模型对他们太抽象了”
“他们不理解对象”
“这样我们就不得不用他们的术语收集需求”

在国外，开发工程师可以很大程度决定产品的设计，实现。
这种极客精神值得我们学习，国内软件开发人员往往需要对产品提出的逻辑进行评审，和谐的团队大家会商量一个实现，不和谐的团队往往出现 产品和开发互相怼的情况。

对于团队的沟通，考虑到国内情况，最好由项目经理完成，项目经理把控整个项目的排期，上线，了解业务，熟悉计算机专业知识，可以充分考虑到各方的情况。

有些计算机专业出身的产品经理，也可以胜任整个角色。

术语的交集产生 ubiquitous language
《领域驱动设计》page 34

三、文档和图

软件设计文档是一部分软件工程师的额痛点，一般的大公司都有自己的文档模板，文档最全的公司应该是专业的外包公司，由于需要交付，文档成了交付必备的内容。

对于互联网行业，文档往往不被重视，大多时候业务的压力使得开发没有时间拟写文档，甚至于产品的需求文档都没办法给出。

3.1流程图

无论你使用什么模型来开发你的系统，流程图都是必须的

对于团队成员来说，流程图都是通俗易懂的
流程图偏向业务的理解。
注意团队成员流程图需要统一画图工具，流程图可以存档编辑。

3.2 交互图

交互图往往是泳道图的形式，涉及到多个模块的业务交互。

3.3 UML 模型图

UML建模是领域驱动的基础技能，对于大部分计算机专业也是必修内容。

3.4系统设计概要