DDD 系列 2 —— 运用领域模型
作者：程序员罗尼 ｜ 发布：2022-12-17 ｜ 原文：https://mp.weixin.qq.com/s/EP6JcqJRr5yjv3rRtJLy0w
上文对 DDD 为什么会存在做了一个介绍，这篇开始正式进入 DDD 的理论和实践。
本系列还是以《领域驱动设计》这本书为主要框架，所以我们以书中的结构来组织文章。本书一共分为四大部分：
- 运用领域模型
- 模型驱动设计的构造块
- 通过重构来加深理解
- 战略设计
前三部分是战术设计的范畴，第四部分是战略设计的范畴。这篇文章主要介绍第一部分：运用领域模型。
模型的三个作用
领域驱动设计的核心是模型驱动开发，所以如何获得和运用领域模型是重中之重。这里先介绍一下模型的作用，主要有如下三点：
- 领域模型是浓缩的领域知识，是对领域知识进行结构化的组织和有意义的抽象。
- 领域模型是通用语言的中枢。通用语言是 DDD 另一个核心的实践，DDD 的整个体系都是围绕着领域模型和通用语言展开的。
- 领域模型要能指导实现，并和实现紧密地联系在一起。
同样，这三个作用也指导着我们如何创建一个好的模型。下面介绍一下得到一个好模型要遵循的三个实践。
实践一：知识消化
知识消化的目的，是为了得到一个知识丰富的深层模型。这里有两个指导原则：
- 开发人员要和领域专家紧密合作，围绕着模型来学习领域知识。
- 持续学习。模型不是一次就能完善的，需要不断地设计和试验，反复打磨。
最开始我们对领域知识知之甚少，模型可能比较粗糙。但是随着不断地消化领域知识，不断地迭代和精化模型，模型的表达能力会越来越强。做好以上两点，才能得到一个好的模型。
实践二：建立通用语言
建立通用语言的主要目的是提高沟通的质量。双方使用通用语言进行沟通和建模，能保证领域专家和开发人员对通用语言有相同的理解，也就是我们常说的 on the same page。
通用语言是面向业务的。使用通用语言可以避免沟通上的隔阂，不但能帮助开发人员了解业务，还能在建立通用语言的过程中解决业务人员的一些模棱两可的理解，同样帮助业务人员加深对业务的理解，双赢。
建立好通用语言之后，开发人员和业务人员都应该基于通用语言来描述系统中的工件、任务和功能，并且坚持使用，不达到流畅的目的誓不罢休。随着通用语言的完善，大家对领域的理解会变得更清晰、更具有一致性，也更有利于创建更深刻的模型。
建立通用语言是一个持续的过程，而且应该在整个软件的生命周期中一直坚持这一实践。
通用语言的来源
究竟哪些概念和词汇可以构成通用语言，哪些不是呢？
首先看通用语言必然会包括的内容：
- 领域模型术语
- 限界上下文的名称（战略设计，后面文章会讲）
- 大型结构术语（战略设计，后面文章会讲）
- 建模模式的名称（后面文章会讲）
然后再看一下哪些可能在开发过程中成为通用语言：
- 开发人员不理解的业务术语（可能表示尚未开发的业务）
- 每个人都使用，但却不出现在设计中的业务术语（可能表示业务中有隐藏的概念没有被发掘）
最后看一下哪些不属于通用语言，主要是用于技术人员内部讨论的一些概念和术语：
- 设计中的技术方面（与业务无关）
- 技术术语（与业务无关）
- 技术设计模式（与业务无关）
实践三：通过模型来指导实现
通过前两个实践，我们应该得到了一个比较好的领域模型了。但要想发挥 DDD 的最大价值，还要通过模型来驱动开发，让模型和代码紧密地联系在一起。
当需求改变的时候，先在模型上体现变化，然后再修改相应的实现。如果模型不能指导实现，可能会导致在模型中分析得头头是道、但却无法落地的情况。这样的纸上谈兵是没有意义的，即使代码最终实现了软件的功能，也一定是难于理解和维护的，因为通过代码无法了解系统的目的和完整的领域知识。同样，如果模型很好，但是实现却没有忠实于模型，那也是不行的。
两个原则
通过上面的三个实践，我们可以得到下面两个原则：
- 如果模型不能准确地描述领域概念，那么需要重新设计它。
- 如果模型不能指导程序的实现，也要重新设计它。
小结
到此，第一部分"运用领域模型"就介绍完了。
对于构建领域模型的前两个实践——一是不断地消化领域知识，二是不断地完善通用语言——理解起来很容易，最主要是在开发过程中要坚持实践。
构建领域模型的第三个实践是最复杂的，因为软件开发主要就是设计和实现。我们在这里只是说了模型和实现要紧密地联系在一起，那么，怎样建模才能使模型和实现结合得更紧密？这就要求我们在设计模型的时候，分析领域的不同概念，根据不同的特征定义不同的模型元素；然后在实现的时候，针对每种类型的元素使用一些已验证的建模模式和最佳实践，创建出忠于模型的实现。
后面的文章会介绍一些用于领域建模的模式和最佳实践，也就是本书的第二、三部分。这篇就到这里了。
（完）