领域驱动设计 pdf_领域驱动设计浅析（一）——统一领域语言

　　领域驱动设计(DDD)，自微服务设计模式兴起，作为该模式的设计理论一下就火热了起来。在网上充斥着大量的相关教学课程与相关文章。但是，常常是在看了各种课程之后，在实践中依然会遇到很多问题，也常常有人来问设计相关的一些问题，所以才有了想写本系列的想法。

　　这里并不像是作为领域驱动设计的教学篇，而是就其中的一些实践关键点做一些分析，方便解惑。

　　本篇作为开篇，想讲的是领域驱动设计的关键核心：统一领域语言(UBIQUITOUS LANGUAGE)，这点在项目实践中，非常容易被忽略。

　　为啥需要统一，可以设想这样的一个场景。

　　在业务建模阶段，业务专家和技术专家坐在一起讨论。你会发觉双方在理解上往往会存在着极大的分歧。参与过系统业务需求讨论的开发同学一定有这样子的心得，对方在说什么？为什么象在听天书一样，说的每个字都听得懂，但是双方理解很难一致。究其原因，就是因为双方的日常工作所处的专业领域各有自己的术语。平时已经习惯性认为听者具备与自己具有同等专业领域知识，那么当业务专家与技术专家坐一起讨论，双方在理解上的一致性冲突就不难理解了。古巴比伦通天塔的失败，就是因为上帝让人们的语言不再相通，而中国成语中对牛弹琴、鸡同鸭讲等等也是描述的相同问题。

　　因此在项目初期，领域驱动设计首先强调的是必须要建立起这样一个描述语言模型，使得业务和技术双方能够以此作为整个项目建模的讨论基础，来开展后续工作。

　　上述是使用统一领域语言的原因，那么具体怎么做呢？

　　这里讲一个惯常使用的简单办法----名词定义表。

　　首先将讨论过程中，所有涉及的具体业务术语(包括名词和谓词)都记录下来。

　　其次对这些术语做一个双方理解完全一致的具体定义，其内容可以包括单不局限于通俗解释、前提、具体流程、产出物、对其他业务的影响等内容，且最好是将对应的英语术语也标注其上。

　　后续所有项目相关工作都基于该表来进行，并随着工作开展需要不断维护修订该表以保证准确性和完备性。该表对项目成员应完全公开并能无障碍获取，项目相关方都可以针对该表提出补充说明和新增内容的需求，并由建模人员负责进行统一审核修订。

　　以上，是关于领域驱动设计中统一领域语言的一些实践认知，希望对大家有帮助。

作者：徐瑱老师