唐霜的博客

今天学到的新知识点，领域模型 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还非常少见。

在 react 状态管理领域，react-redux 可谓是只手遮天了，基于 flux 思想实现，小巧，immutable 的思想让数据变化可控。但 immutable 所带来的编程代价太大了，如果你要更新一个深层结构的对象的某个节点，写作将会是极其麻烦的一件事，而且还保不准会出错。为了保证 immutable，redux 的 reducer 机制让开发者掉光了头发。于是有了类似 dva、rematch 等这样的项目，这些项目基于 redux 再做了一层封装，让开发者少写了很多 reducer 相关的代码，但是很无奈，immutable 的特性，让开发需要付出更多的精力来控制每一个更新。

再另一个世界，mutable state 其实也非常优秀。知名的 mobx 推出了 mobx-react 和 react-redux 竞争。然而，原本非常优秀的 mobx 却只管把自己的想法强加于人，而忽视了代码写作的便捷性，总之，使用起来虽然不用再为 reducer 头疼，却对组件的侵入和让人很不适应。你需要了解它的概念，特别是基于观察者模式的很多概念，它提供的 api 的形式也很丰富，基于接口的、装饰器的，总之，你在掀开它的魔法盒子时，会忍不住“wo\cao/”，但当你真正在项目中尝试使用它时，确会不由但发出“wo^cao\”，但就在心智折腾上，就让人抓狂，还不知道会产生多少副作用 bug。

在 mutable 数据管理最优秀的，莫过于 vue。无论初识还是长久，都会与 vue 的响应式数据相看两不厌。它简介的用法，以及把基本原理告诉你，让你尽情去修改数据。Mutable 相对于 immutable 的最大好处，就是可以对对象任意节点上的对象进行修改，而无需仔细的把握这个节点在整个 state 的什么位置上，在 redux 的实践中，你可能都已经厌烦了写 ... 来解构对象/数组了，但在 vue 中，根本不需要担心这一个点，直接逮住一个对象，立即修改它的某个属性，完事走人，不需要先构造出一个新的数据，不需要调用某个接口把这个新数据传入进去。虽然 redux 那种每一个状态都是全新的思想很好，但是，你的状态不可能是全新的，每一个被认为是全新的状态，都包含了老状态的一部分（对象节点），而这些引用，可能带来后续的错误。在 react 生态中，你可以使用 immutable.js 来尽可能避免这个问题。

但是在 vue 生态中，用于管理全局状态的 vuex 确非得要引入 mutions, actions 的概念，这都是从 flux 借鉴过来的，而且很奇怪的是，在 mutions 中定义的修改，又要到 actions 中重做一遍。实在是有点自废武功啊。有没有一种方法，可以在 react 中真正享受 vue 式的数据管理？你不妨来试试下面的代码：

function MyComponent(props) {
  const { one } = props
  const { name, age, height, married, sex, changeSex, me, book, updateBook } = one
  return (
    <>
      {!!me && (
        <>
          <span>{me.user_name_zh}, {me.user_position}</span>
          <br />
        </>
      )}
      <span>{name}: {age}, {height}, {married ? 'married,' : ''} {sex ? 'F' : 'M'}</span>
      <br />
      <span>book: {book.price || 0}</span>
      <br />
      <button type="button" onClick={() => one.age ++}>grow</button>
      <button type="button" onClick={() => changeSex(!sex)}>change</button>
      <button type="button" onClick={() => updateBook({ price: (Math.random() * 100).toFixed(2) })}>update</button>
    </>
  )
}

const mapToProps = (contexts) => {
  const { one } = contexts
  return {
    one,
  }
}

export default connect(mapToProps)(MyComponent)

看这代码啊，和 react-redux 有点像，完全可以理解是不。

在数据开始对组件进行注入的时候，保持和 react-redux 一致的使用效果，这实在是无缝的思想过渡，你觉得从原来写 react-redux 的代码到写这样的代码，会有压力吗？没有，一点都没有。下面来看看这种全局状态管理的真面目：

import React from 'react'
import { use, connect } from 'react-tyshemo'

class Book {}

use({
  name: 'one',
  state: {
    name: 'one',
    age: 10,
    book: new Book(),
  },
  computed: {
    height() {
      return this.age * 5
    },
  },
  watch: {
    age({ value }) {
      if (value > 22) {
        this.married = true
      }
    },
  },
  methods: {
    changeSex(sex) {
      this.sex = sex
    },
    updateBook(data) {
      Object.assign(this.book, data)
      this.dispatch('book')
    },
  },
  hooks: {
    onUse() {
      fetch('/api/me').then(res => res.json()).then((json) => {
        const { data } = json
        this.me = data
      })
    },
  },
})

看完什么感受？“wo/cao/” 绝对是抄 vue！连属性名字都和 vue 组件一毛一样（多了一个 hooks）。用一个 use 函数注册一个 state 的 namespace，并且这这个注册定义对象中，传入 state, computed, methods, watch 等来实现状态数据的处理。由于对数据的操作和 vue 是一摸一样，所以，你不用担心 ajax 请求的异步问题了，不需要考虑一大堆 redux 带来的“解决问题带来的问题”。而且，react-tyshemo 只提供几个函数接口，避免 mobx-react 那般复杂。

看上去是不是很舒服呢？

马上体验