换个思维学领域建模方法和实践

╰半橙微兮° 2022-12-13 04:55 157阅读 0赞

转自：[https://www.infoq.cn/article/6hpBsMXQNGx\_EAPKUuWS][https_www.infoq.cn_article_6hpBsMXQNGx_EAPKUuWS]，大佬文章建议看原文哈

## 引言 ##

对于具备三、五年开发经验的同学而言，可能会接触到领域建模。如果公司规模较大，可能会更早接触这一概念。但是，领域建模好像一座高山，很难越过。目前，业界提出了很多方法建模，但没有一种被公认是最好的方法，大部分建模取各家之长，这也使得这一概念变成"只可意会而不能言传"。本文将分三部分讲解这一概念：为什么领域建模这么难、换个思维学领域建模以及领域建模要回答的三个问题。

## 二、为什么领域建模这么难 ##

为什么领域建模很难？大致可从如下 5 个方向谈起：急功近利的心态、被高深的理伦吓到、迷失在方法选择上、忽略实践的重要性、思维模式。

### 2.1 急功近利的心态 ###

我把技术分为两种：一种是快技术；另一种是慢技术。快技术的特点是门槛较低，一学就会，学会了很快就能应用；慢技术的学习具有一定周期，见效并不快。

领域建模在网上也能搜索到几本书，阅读后普遍有一个感受：并没有教会你怎么去做。并且，实际工作中不见得能遇到、用到，所以慢慢就变得高深莫测。

### 2.2 被高深理论吓到 ###

领域建模中有很多名词，如界限上下文、聚合根等，初期接触这一概念时，面对这些扑面而来的概念，有些人可能就直接放弃了，书中的案例在生活中接触并不多，陌生、不理解让开发者与领域建模渐行渐远。

### 2.3 迷失在方法选择上 ###

领域建模并不是没有方法，而是选择太多，有用例法、四色建模、领域驱动建模、事件风暴等，人有一个特点是喜欢找最简单、最易用的方法，每个方法都有自己的特点，并没有好坏优劣之分，只有适不适合。听到一个方法就去尝试，尝试到一半就放弃，一种种方法尝试，最终就会迷失在方法选择上。

### 2.4 忽略实践的重要性 ###

领域建模是一项十分强调实践的技术，它有理论的部分，但我认为更多是要实践，空谈一个东西收获并不大，只有实践并画出领域模型，与专家交流，才能有所收获和成长。人有时的迷茫是在于没有找到确切的点去做，大部分时间浪费在举棋不定上，一句话：干就完了!

### 2.5 思维模式 ###

在技术思维上，我喜欢用"盲人摸象"的案例，包括我自己曾经喜欢陷入细节中，并不是细节不重要，人的认识一定是宏观到中观再到微观，如果一开始就进入微观，连全局的概貌都没看见，最终可能会南辕北辙。

因此，学习技术也一样，先从整体思考，为什么有这项技术，它到底解决了什么问题，又是通过什么样的手段去解决的，这样的思考比掌握一个小的奇技淫巧要强得多。

## 三、换个思维学领域建模 ##

### 3.1 领域建模到底解决了什么问题？ ###

我们不能高度化领域建模，领域建模也不是包治百病的技术，一句话讲领域建模的根本目的就是统一认识、减少沟通成本。

有的人看后可能很失望，就这么简单？是的，就这么简单，领域建模的本质目的就是这样。但同时又不是这么简单，统一认识、减少沟通成本，这句话听起来很简单，但其实有两个层面的含义：一是工程技术规范、二是业务认识。

工程技术规范是指我们有一套业内规范、行话。举个例子，一说到设计模式，谈到一个具体的模式、约定，大家都懂，不至于还要询问这个模式是怎么样的。

业务认识是统一业务、开发、测试、产品的认识，大家讲的都是一个东西。其实要做到这一点是很难的，开发喜欢从技术层面去描述问题，产品习惯从业务层面描述问题，两个不在同一个频道怎么能好好沟通。在小团队这种优势表现不出来，在大团队中，沟通成本是很高的。

领域建模就是干这个事，把模型建出来，因为一图胜千言。不管谁看了，从模型中统一大家的认识。

从而得到我们总结的第一个结论：领域建模是解决统一认识、减少沟通成本。

### 3.2 从已知经验推导领域建模的过程 ###

此外，不急于进行领域建模，先从熟知的场景入手，看看之前是怎么做的。在读书阶段，不管是小学、初中、高中、大学，学习语文经常做这么一件事：概括文章中心思想和段落划分。

一般而言，在分析一篇文章之前，首先了解作者、写作背景；其次，通读整篇文章，获取文章大意；然后，细分段落分层，理解每段大意；最后，整合整篇文章的中心思想。

综上，这是一个典型的抽象过程，最后得到的中心思想和段落分层就是一个模型。到这里不知你想到了什么，下面我再戳破一层纱：段落分层就是业务流程中的节点，多个段落里的内容是支撑该流程的节点；每个段落分层一定有核心点，这个核心点就是组成文章中心的一部分。抓住这几个核心要点就等于掌握了整个文章的主旨，再深入分析每个要点下面是如何支撑的，是举例陈述还是讲道理还是反衬等。这样做下来，既能站在主层次看整个流程 (起承转合，布局层面)，又能深入细节看具体内容。

从而得到我们总结的第二个结论：无论如何，领域建模一定要找到业务的流程节点，找到业务流程节点就成功了一半。

## 四、谈领域建模应该要回答的三个问题 ##

这里要回答困扰大家已久的问题：到底要怎么建模。要回答怎么建模，我想从领域建模这个概念上回答三个问题：领域是什么，模是什么以及如何建。

### 4.1 领域是什么？ ###

领域在百科中的解释是"学术思想或社会活动的范围"，“的"前面的都是修饰作用，重点关注名词是"范围”，所以，不同领域有不同的范围。换言之，讨论的领域有具体范围。现在所说的领域建模是泛指，一般要加限定词，如商品领域建模、优惠券领域建模等。  
我们得到的第三个结论：谈建模一定要限定范围。

### 4.2 模是什么？ ###

模是模型，同样在百科中的解释是"通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的物件"，从这句话中可以解读如下意思：

*  首先，这是一种表达目的物件，这个很好理解，通过该模型就知道有什么，这也是建模的目的，一图胜千言，统一认识。
 *  模型结构是客观存在的，所以，任何业务都有一定模型，因为它是客观存在的。
 *  需要不断认识并构建模型，因为是通过主观意识构建，需要现实接触或者通过其它手段了解事物。

反映到业务上，模就是业务场景的映射，换言之，通过模型就能推导出业务场景，反之也一样，通过业务场景也能推导出模型。业务流程中包含业务场景，所以之前就说过抓住业务流程就成功了一半，具体的流程节点往下细分就会有一系列业务场景。

我们得到第四个结论：模是业务场景的映射，不懂业务无法建模。

### 4.3 怎么建模 ###

终于到核心点了，我们在各种书籍上苦苦追寻建模的方法，但没有人告诉你要怎么去做，我分享的方法也不是独创的，也是根据各种方法的优点总结而来。

领域建模方法一直都有，包括用例建模、四色建模、领域驱动建模、事件风暴等，我想分享一种通用思路去建模。在怎么建之前，我还是想让大家固化几点认识。

### 4.4 建模前定律 ###

**4.4.1 业务是建模之母**

其实上面已经有这样的结论：模是业务场景的映射，不懂业务怎么能建模。为什么我还要在这里强调，是因为大部分做技术的不太喜欢做业务，觉得做业务没有价值，不就是 CRUD 么。不是说领域有多难建模，而是我们在业务上投入的时间少。  
首先你得把业务摸清楚，能画出关键的业务流程，熟知业务的具体运转，否则怎么能建模呢，脑海里对业务一团遭，建得好模型是见鬼了。  
我们得到的第五个结论：业务是建模之母。

**4.4.2 任何业务都存在一条稳定的业务流程**

模型是客观存在的，只是你能不能把它画出来。要画出领域模型，它的方法是从业务流程入手，没有找到业务流程很难画出领域模型 (不管你用什么方法，虽然叫法不一样，实施流程不一样，但有些本质思路是一样的，这个大家可以自行体会)。所以，画一个领域模型时，不管通过什么途径找出其业务流程。

在《系统架构 - 复杂系统的产品设计与开发》一书中提到"标准蓝图"的概念，也是同样的意思。业务流程非常关键，是业务的灵魂，脱离了这个主线，就会不见森林，只见树木。

我们得到的第六个结论：任何业务都存在一条稳定的业务流程。

**4.4.3 业务流程中的节点，每个节点都会有产物出现**

在找到业务流程后，比如优惠券业务，其流程是建券、发券、用券，每个流程都会有产物，建券的产物就是券模板 (券批次)，发券的产物就是券实例，所以这里的产物就是整个业务骨架，这和四色建模中的时序对象一样，综合了四色建模和事件风暴的方法。

所以讲这些定律就是让大家相信，通过这些可以建立领域模型，先不要怀疑，完全熟悉后再扩展自己的想法，而且这些定律是一层套一层的。

我们得到第七个结论：业务流程中流程节点的产物就是业务骨架。

### 4.5 领域建模的方法步骤 ###

以上定律是让大家从意识层面记住重要的点，在实际操作中会不断用到以上结论。下面就具体从实际可操作的方法上分析领域建模。

**4.5.1 找出业务主流程**

第一步是找出业务主流程，这是业务的生命周期，不管怎么讲，任何业务都有一套稳定的业务流程。当接手一个新业务时，先不要急着想领域模型，当按照我分享的步骤去分析业务时，领域建模自然会水到渠成展示出来的。

类似上面的优惠券业务，业务流程就是建券、发券、用券。业务主流程每个流程节点都会有一个产物出现，这个产物就是业务的骨架，在这个业务下，它的产物是券批次、优惠券实例。注意，它仅仅是一个骨架，但至少找到两个关键领域对象。

**4.5.2 细分业务主流程**

这一步是在主流程基础上继续分析子流程，主流程能让我们知道整体的业务流程，但还有些细节流程是在子流程中，比如建券是一个大流程，那么我们马上会问，这个券长什么样？有哪些关键属性？等，是不是多问几个为什么马上让我们就深入到业务细节了。

再比如发券过程，需要经过一些检查，如规则检查、风控检查，最后才是发券，这样分析下来，我们对业务掌握得越来越深入。上面提到我们分析出的两个关键领域对象，此时再从两个方面考虑：一个是其它对象关联，或者包含券模板和优惠券实例；另一个是券模板或者优惠券实例包含其它。

**4.5.3 抽象**

从第二步中，我们得到更多具体对象，但此时要进行合并整理，并不是直接加到券模板或者优惠券实例关联部分上，这个过程是不断打磨的过程。

上面就是领域建模的三步方法：找出业务主流程、细分业务主流程、抽象。没有任何高深的理论、简单朴素的方法，至于为什么觉得简单，是因为前期铺垫唤醒了你之前的经历，再去做相似的事就会觉得有熟悉感。  
我们得到的第八个结论：领域建模源于业务，又服务于业务。

### 4.6 优惠券领域建模实例 ###

现在拿一个具体的例子来讲如何进行领域建模。

**4.6.1 优惠券业务流程**

优惠券的业务主流程如下图所示，整个流程划分为：建券、发券、用券、退券。

![f22dceebcb2da3d97d36dfca50c6f847.png][]

上面是一个大的流程，大体上知道券的生命周期是怎样的，接下来要分析每个流程有哪些内容，哪些产物以及这些产物就是领域里的关键对象。

![407c0df58c16824f64fe9a7488af763b.png][]

以上图为例，几大产物分别是：券批次、券实例、用券明细、退券明细。

*  券批次：配置域中运营建的券，它有券规格信息 (名称、有效期、券类型等) 和券的领取 / 使用门槛信息
 *  券实例：就是用户看到的一张实实在在的券
 *  用券明细：记录券什么时候被使用
 *  退款明细：记录券什么时候退还

因为优惠券与活动相关，所以这里也把活动相关的信息也提一下，这样就更完善。到这里可以把这几个对象先记录下来。

![f4fd43be3eb49b3edc590c02caf19b15.png][]

基本上通过这个模型可以看出一个券批次会关联一个券活动，券活动有相应预算，用户领取后就会产生券实例，一个券实例会经过核销，又会产生券明细。通过这个模型能看出优惠券业务中涉及的关键领域对象，不管是开发还是产品、业务，看图一目了然。

**4.6.2 领域对象打磨**

上面算是一个骨架，接下来丰富这个骨架。丰富过程基于流程分解，在每个子流程中都操作了什么，其实我们多问几个为什么也会深入下去，这个优惠券的样子是什么、包含了哪些内容等。

![a4d67434a81e102d117ba787aea3a603.png][]

这张图就更细了，通过这个就知道优惠券有什么，不用看代码就知道优惠券的业务有哪些。

## 五、小结 ##

本篇文章从学习领域建模难的问题谈起，列举了一些点，然后通过我们熟知的经历去看文章怎么划分段落。讲领域建模，一定要讲怎么建，而且是可落地实操的，否则理论一大堆，却不会用。

[https_www.infoq.cn_article_6hpBsMXQNGx_EAPKUuWS]: https://www.infoq.cn/article/6hpBsMXQNGx_EAPKUuWS
[f22dceebcb2da3d97d36dfca50c6f847.png]: /images/20221123/41726b839d314f68b0e4fab3612762c3.png
[407c0df58c16824f64fe9a7488af763b.png]: /images/20221123/11e82bcef0294149bc1b085cdae60ad8.png
[f4fd43be3eb49b3edc590c02caf19b15.png]: /images/20221123/ce3af35773e74fb0a0b93e2034f016de.png
[a4d67434a81e102d117ba787aea3a603.png]: /images/20221123/a5f2f497d5904919849f10d5f59b4be5.png