今天学到的新知识点，领域模型 Domain Model。简单总结一下，什么是领域模型？领域模型有哪些好处？如何在开发中运用领域模型？

什么是领域模型？

有两个领域对领域模型做出解释。

• 管理领域：领域模型是对整个行业的工作模式的抽象总结。
• 软件领域：领域模型是对对象普遍性的最高抽象。

虽然出发点不同，但是实际上表达意思的核心思想是一致的。要理解领域模型，首先看下“领域”的概念。横向比较，domain对应的是range，domain是定义域，range是值域。纵向对比，领域是比专业/职业/业务更高水平的概念，例如我们经常说“机器人领域”“水产品领域”“航空航天领域”。“领域模型”概念的核心思想，就是寻找某一宽泛范围内的行为模式的共性，抽象为可适用于这一范围内所有行为的普遍性原则、规律或方法。

在编程领域怎么去理解？从大的层面讲，电商类应用与OA办公应用是两个领域的应用，它们适用不同的业务领域模型。从小的角度讲，用户鉴权和订单跟踪这两个业务完全不同，适用不同的编程领域模型。这里你可以发现两个点：1）虽然鉴权和订单领域模型不同，但是这两个业务之间可能存在联系，比如是否得到订单信息基于鉴权的结果；2）虽然电商应用和OA应用业务场景不同，但是它们可能都需要鉴权。

所以，从编程角度看，领域模型实际上既要解决对象抽象的问题，也要解决对象间的关系问题，还要解决在什么事件下触发对象关系的转变问题。

领域模型有哪些好处？

这里的好处是指相对于业务模型来说。我们开发过程中，经常基于业务场景去进行设计。而一个应用系统的开发，必须应对业务需求的变化。特别是办公软件这种系统，一个企业使用办公软件，必然遵循企业管理的流程，而流程变更是常有的事，基于业务场景去设计和架构软件，并持续迭代，最终带来的后果就是在多次迭代之后，不得不进行重构。而如果该次重构仍然基于业务模型去重构的话，必然还会经历再一次的重构。因为一个业务模型是无法适应所有业务场景的。所以，一旦现实中的业务需求迭代了，给原有的技术架构造成必须重构的影响时，开发者没有任何回旋余地。

而如果基于领域模型设计软件，那么可能接受的代价更小。在分析业务本身时，不只为了实现业务去设计架构，而是从行业的普遍性出发去设计架构，同时结合自己的业务特征，再在设计好的架构上包上一层。哪一天自身的业务发生变化，往往只需要在上面包的那一层上做调整。在软件整体上，分不同的层“视图层-业务层-数据层”，在每一层中又具体的去划分，比如业务层“领域模型-业务模型-流转模型”。而且在设计之初，每一个领域（鉴权、订单等）都采用行业标准，再在行业标准基础上包一层实现定制。那么这一就可以以最小的成本，把知识沉淀在自己的真实业务代码中。

如何运用领域模型？

以下是我在这篇文章中看到的建议。

• 理解后端领域模型
• 建立前端领域模型
• 分离领域层
• 主导接口约定
• 开发中注意业务含义
• 实时同步

简单讲，就是要建立抽象类，这些类去定义领域对象的属性、方法，而且这些类要有一定的内在联系，可扩展。在视图层可以被很好的使用，并不需要在视图层去撰写业务逻辑。

一些相关话题的文章：

• https://juejin.im/post/5d3926176fb9a07ef161c719
• https://zhuanlan.zhihu.com/p/37904835
• https://juejin.im/post/5b1c71ad6fb9a01e5918398d
• https://zhuanlan.zhihu.com/p/109114670
• https://www.jianshu.com/p/fe45506ea358
• https://zhuanlan.zhihu.com/p/59886663
• https://www.cnblogs.com/luminji/p/3703082.html

另外，刚才在阅读的时候，发现“视图模型”“业务模型”“领域模型”这些概念。现在前端编程实际上大部分是杂糅“视图模型”和“业务模型”，也就是MVVM中的VM那一套东西，真正的MVC还非常少见。