基于上下文的业务流建模法(一)

一、背景

DDD相关的建模方法就目前看已经在实践的建模方法已有6种之多，之前的技术分享中也有大佬尝试通过一些新的方法或者理论来帮助统一DDD建模，这其中的原因也是因为希望找到一个比较好的或者适用性更广的建模方法。

当然我也在思考这个问题，并且尝试用一些新的方式来优化当前已经使用的建模方法中存在的缺点。因此在本系列中我将尝试通过3篇左右的文章来提出一个新的建模方法，有可能读完之后感觉就是之前所有的建模方法的结合体，但是这并不妨碍你更好的运用建模方法来构建软件模型。

二、需求

为了更好的表达本文的核心宗旨，这里我简单将这次建模方法的构建之旅称作：寻找更好的建模方法。当然也希望多多讨论，我觉得这个构建过程会比较有趣。

三、建模核心诉求

之前的文章已经表达过不同的建模方法的优缺点，这里不再赘述。但是为了构建一个更好的建模方法或者提出一个方法论需要解决的核心问题是什么？为什么要建模？建模方法需要解决建模过程中的哪些需求？这里我将建模方法本身的需求分为五个部分，可以参考：

3.1 需要表达模型

建模方法需要对相关概念,需求或者现实生活中的人事物等通过一定的形式表达出来，并沉淀到文档中。

3.2 需要表达行为

建模方法需要对模型中的角色所产生的行为通过一定的形式表达出来，同时不影响模型本身。

3.3 需要表达事件

建模方法需要对整体领域模型中的不同业务对象存在的事件进行特别标注，通过事件流程来看模型的行为和业务流程。

3.4 需要表达流程

建模方法需要在一定程度上支持业务流程的在模型上的体现。说白了建模方法除了需要表达模型本身的同时我们也希望通过运用建模方法来构建业务流程，将流程和模型统一。

3.5 需要表达角色等人事物

上面的表达行为和事件等都是我们在分析业务并准备建模落地的生活需要关注的，但是大多数情况下我们还需要关注到整个模型有哪些人参与，哪些人属于什么角色，哪些事物与哪些模型有关系，但是我们却不方便在模型中表达。

从我对建模方法的需求来看，之前提到过的建模方法大多无法完全满足以上5点内容，或者仅仅满足2-3项。当然很多软件研发的前辈都在尝试用更好的方法来帮助建模，我这里也小小捣鼓一下。

四、上下文胶片

在正式介绍这种建模方法之前先看一下电影的制作过程。我们可以从电影中得到一些启发。

4.0 电影的制作过程

这里我从百度百科上面简单总结了下整体上电影的制作过程，步骤如下：

拍摄前的工作，包括提构想、写故事、分场大纲、签导演、列预算、编剧本、看外景、找演员，以及决定制作小组的成员。
拍摄中的工作，即在导演的指挥下采密集作业方式进行，并由执行制片监督经费开销、拍片进度和一切行政事宜。
拍摄后的工作，包括剪接、配音、配乐、设计字幕、制作预告片，以及展开上片前宣传等。

当然这是整体的制作过程，类似于分布式微服务的整体构建过程，那现在我们看一下电影的拍摄过程涉及到哪些内容，这里我们将工作范围缩小一点，就是演员在拍摄地点完成拍摄过程。所以不难看出一个拍摄的片段会涉及到背景，演员表现，导演等拍摄小组的拍摄等。当然还有服装，化妆，动作指导等等。这些都是在拍摄现场完成的。

话说回来，这么多人在一个拍摄地点或者一个摄影棚中可能就只拍某一集的一部分片段，在另外一个地方拍另外一些片段。那么到后期就是整体的电影内容制作了。所以我们可以看一下软件方法中的建模也是如此，如果是一个比较简单的系统，我们构建模型也会很容易，类似于现在很多人拍的抖音短视频或者快手短视频。

4.1 说明

每一个上下文可以是一个桥段，一个行为可能就是电影中的一个角色的动作，就那么几秒。那么对于整个app或者后端应用来说，随着请求和业务场景的变化，上下文和模型都在跟着变，因此我们可以把上下之间的依赖全部链接起来，将模型，行为，事件，流程等融入到业务流程中，像放电影胶片一样一点点构建出来。

4.2 建模过程类比

这里我将建模过程与导演拍电视剧/电影进行对比，把拍电影所需要协调的人，时间，动作，背景，场地，效果，故事情节全部融合在一起。所以为了整个建模过程顺利完成，还需要一些东西来承载这些内容，说白了我们需要找到合适的工具来当一个背景墙。比较常见的一个背景墙就是UML了。

4.3 业务流建模模板图

这里我通过一个业务流建模模板图来简单说明一下这个建模方法的核心内容，首先我们仍然是以时序图为模板，但是时序图的核心参与方是领域，领域服务，上下文级别的。重点在时序图本身的内容中是要表达模型，行为，事件和流程，以及相关的角色人事物。说白了就是通过时序图来将需要表达的东西构建出来。

因为常规的时序图做法中有很多图标或者线条线段会比较专业而且单从时序图上看就可以表达流程本身，但是这里需要把时序图扩展一下，就是时序图要表达模型的核心字段，模型的行为和触发的事件，模型在上下文中是如何流动的。因此，只要时序图整个背景墙足够宽或者足够深，即可表达整个业务流程和模型相关的内容。当然也需要二次加工来构建比较纯净的业务模型和业务流程，以及上下文之间的关系。

图里面的一些元素目前还没有硬性规定，所以还需要逐步摸索一套适合自己的表达方法。重点是灵活，够宽。

4.4 业务流建模模板图V2版本

注：
这里根据林老师的建议我对上面的一些元素标签或者线段做一些标注，方便在实际运用的过程中进行统一认识，所以对上面的图做了优化：

为了更清楚的表达这个图的含义需要说明一下整体图的元素内容和作用

领域，上下文，和模块

建模过程中我们先通过自顶向下的方式预先定义几个大概的领域，领域服务，上下文或者模块，算是粗粒度的时序角色。

每个领域或者上下文已知的实体，值对象，聚合根和其属性

这里在基于核心领域或者多个领域建模的时候我们先对每个领域大概有哪些实体，值对象和聚合根等信息，这里的内容依然是草稿阶段，也就是说在建模过程中领域，上下文，和模块以及这一部分内容都是可以动态修改的，比如实体需要挪到另外一个上下文中，这里的信息仍然是从需求或者统一语言里提炼，来帮助构建一部分核心信息，为下面的业务流图提供参考。

基于整个领域元素(包括模型)构建的业务流

这一部分仍然是以领域元素来构建的业务流图，所以没有一些专业的流程时序控制(比如分支,并行),这一部分的作用有以下几点：
1.模拟业务流程中的领域模型如何协作，数据流在粗粒度的模型下如何流动，以及针对聚合或者比较重的业务流程我们需要什么样的领域服务(service,factory,gataway)来辅助构建流程。
2.在不同业务流程中帮助补充领域模型相关的字段和发现新的对象模型(比如事件，消息msgbody)。
3.验证划分的上下文或者领域里的相关实体是否与之相互匹配，不匹配则重新构建上下文。
4.多人一起构建的时候可以进行头脑风暴来一起评估当前业务流图是否已经符合业务需求或者是否可以相对完整的表达领域模型。

右侧的标签列表

这里的标签也是根据林老师的建议通过建模方法元模型来整体规划下这个业务流图中的元素，这样看上去会比较统一同时也整洁很多。当然实际情况下我们可能需要不同组合的标签贴到业务流中，所以这里我组合了一些常见的标签列表，每个标签组在业务流图中都是可以编辑的。

4.5 基于上下文的业务流建模法

通过类比电影拍摄过程来构建建模方法，这里我从领域上下文结合业务流程作为切入点来简单阐述一下基于上下文的业务流建模法的提出过程。另外一方面跟进业务的特性很多系统会有多个业务流程，这也牵扯到多个业务上下文，因此从常规的角度来看我们不得不跟着业务流程走，这样也让我们很容易忽视业务流程对整体模型的影响。所以这里会以业务流为重点来说明这个建模法的侧重点。