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

一、背景

上一篇文章说到了我提出了一种新的建模方法，并对建模方法的大概内容做了阐述，本次我将继续对这个建模方法做进一步的说明,并提供一个小小的案例来熟悉一下建模套路。下一篇文章将通过其他案例来展示这种建模方法的优势。

二、其他建模方法回顾

这里我从之前的分享资料来给大家回顾一下比较常见的建模方法，当然也有很多书里有一些其他建模方法，这里不再一一列举了，感兴趣的话可以找一下领域驱动相关的书籍和UML建模相关的内容。

2.1 四色建模法

2.2 限界笔纸法

2.3 事件风暴建模法

2.4 基于用户故事的建模法

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

3.1 建模步骤

识别业务领域或上下文
构建业务领域或上下文之间的上下游关系
在业务流图中标注建模标签
按业务领域或上下文归纳建模内容
将领域模型和业务时序分包沉淀到领域文档和业务时序文档中
循环前面5步得到最优最全领域模型和业务时序

注：
根据张老师的建议，这里对上面的建模步骤做一些调整精简和完善整个建模流程：

识别粗粒度的领域上下文或者模块(识别领域上下文)
创建业务流图画布(创建画布)
构建领域上下文的上下游关系(构建上下文关心)
在业务流图中标注建模标签(建模)
按业务领域或上下文归纳建模内容(归纳推演)
从业务流图中提炼领域文档和时序文档(整理沉淀)
循环前面5步得到最优最全领域模型和业务时序(不断优化)
工程编码验证(落地建模，可选步骤)

3.2 建模步骤详解

识别业务领域或上下文

第一步我们需要根据需求梳理已有的领域服务或者上下文，如果没有就是新的，当然领域服务和上下文这里需要选择一个主次关系，前面的建模模板是把领域服务当作主，上下文算是领域服务的一个模块或者模块的代表。当然你也可以不用这么划分。可以是领域上下文，领域服务，或者领域模块等等。
简单来说第一步就是先找到最重要的几个业务领域或者上下文。
注：
根据张老师的提醒，这一步貌似有点唐突或者没有凭据的去产生一些领域或者上下文，所以特别说明一下，这一步也是根据经验或者已知的领域上下文来构建的，相当于一个粗粒度的草稿。在建模过程中可以删掉或者调整。当然领域或者上下文的识别划分在张逸老师的《解构领域驱动设计》中有详细的说明，当然也可以参考我公众号的文章《领域划分的规则是什么？》。
当然这也给了我一个提示，这个方法体现的其实是自顶向下的建模过程，也就是说我们可以不需要自底向上的构建领域和上下文，而是给一个可能的划分方案然后去验证是否划分合理。所以看上去建模的上手难度会简单一些，也就是说你可以凭直觉构建粗粒度的领域模型，然后自己建模验证去验证它，建模过程也刚好是一个不断完善和修复模型本身的过程。

构建业务领域或上下文之间的上下游关系

第二步也是领域划分或者领域服务构建的一个步骤，这里我们拿来构建整个业务时序的前后关系，或者依赖关系。

在业务流图中标注建模标签

这里的建模标签就是你想表达的东西，比如事件，实体，行为，聚合，工厂，领域内发生的实体行为关联关系，上下文调用依赖等等。需要说明的是在这一步中你可以不需要按领域元素去标注所有要标注的东西，比如你可以只标注事件，这样的话就相当于事件风暴建模了，或者你只关注业务流程和数据的流转，这样的话就是8Xflow建模了，或者你只关注角色和用户故事，那就是基于用户故事的建模了。
所以从本质上看我提出的这个建模方法也不是完全的创新，只是改良或者优化，集合了各个建模方法的优点，当然也有一些副作用，后面会说到。

按业务领域或上下文归纳建模内容并调整

前面三个步骤已经把要记录的领域模型信息全部标注上了，这里就需要归纳或者review一下是否合理或者正确，然后归纳整理建模内容。

将领域模型和业务时序分包沉淀到领域文档和业务时序文档中

在第4步的时候需要回顾一下构建的业务上下文和时序还有流程是否完全符合预期，如果符合的话那么则可以将业务流图中的领域模型和业务流程时序分别整理到相关文档上，形成多个局部文档。

循环前面5步得到最优最全领域模型和业务时序

这一步一方面是不断优化当前的领域模型和时序模型，另外一方面也是希望通过这个业务流图来以此为基准对以后的需求变更和迭代提供文档基础，这样整体上的建模过程和文档就不会割裂，对于整体分布式微服务或者一个大型系统来说就有一个比较完善的业务流程时序。

3.3 优缺点

优点

比较灵活,不需要事先从模型出发，结合了多个建模方法的优点，比较适合团队使用，个人的话结合实际需求使用即可

缺点

比较重，如果把全部标签放到业务流图中会显得有点混乱，当然也有一些其他建模方法的缺点。

四、建模案例

通过上面的详细介绍，大家应该大概了解了这个建模方法的核心内容，现在就拿商品中心的领域建模进行一次实战尝试。

4.1 业务流程和上下文说明

业务运营人员通过管理后台curd商品基本信息
需要构建前后台商品类目，属性，模板，sku,spu等信息
库存和价格是需要与商品中心服务单独管控，各自有各自的服务系统维护
创建商品并上架销售流程如下：

4.2 根据建模步骤进行建模

识别业务领域或上下文

根据上面的流程和简单要求我们可以知道业务领域整体上看就是商品领域或者电商领域，但是这样的话就太大了，所以稍微细化一下，那现在将商品核心信息的curd当作商品业务领域，商品的价格服务当中商品价格领域，商品库存服务当作库存领域，审批服务当作支撑领域或者业务审批上下文。

当然，涉及到具体交互的时候我们可以把sku,spu这些信息在业务流程交互中当作商品上下文来看待，然后以此跟其他领域进行交互。

构建业务领域或上下文之间的上下游关系

这里按照业务时序先在各个领域服务或者上下文中标示关键的业务实体或者配置或者服务接口，来表明业务领域或者上下文之间的上下游关系。

在业务流图中标注建模标签

这一步是比较核心的步骤，需要对各个实体标示实体行为，实体引发的事件或者消息,在这一步中先不考虑实体之间的关系，而是考虑整个实体在业务中的表现和业务流程中的影响范围。现在看上去不是很具体，我们看下一步的操作内容。当然这里可以简单参考业务流模版图的布局方式:

注意上面的整个业务流图的布局由三个部分组成，所以这里可以分为两个小步骤：

构建核心领域和支撑领域相关的实体，聚合根，属性等关系
基于用户故事或者客户操作流程来进行业务流的模拟，这也相当于导演在剧组喊了一句:Action.
按业务领域或上下文归纳建模内容并调整

前面三步走完之后，我们可以得到一个大概的业务流图，从图中可以看到在建模过程中有些属性我们需要特别关注，尤其是状态或者某些关键的属性，在一开始构建的时候可能没有特别注意，但是走业务流程的时候就会发现某个属性在业务流程中甚至在当前上下文中是最重要的。
当然以此类推就是，导演觉得这个桥段拍的不好，重拍。在这里我们不需要完全将整个业务流图删掉，而是在这个业务流图中的旁白部分加上，或者直接在上面的实体基本信息中加上。那么在这一步中如果出现了比较大的分歧或者某个实体应该分在前面的上下文或者后面的上下文中，那就需要相对较大的调整来让整体显得更协调而且具有说服性。

将领域模型和业务时序分包沉淀到领域文档和业务时序文档中

在这一步我们可以基于上面的业务流图来构建领域文档和业务时序文档，所以在这一步会产生三个文档图

领域模型文档(plantuml-class)
商品领域本身的业务时序文档(plantuml-sequence)
整个业务领域的时序文档(plantuml-sequence)

这三个文档与上面的业务流图是相辅相成的，如果哪里出现问题可以一起调整，需要注意的地方是业务流图本身承载的信息量有限所以更具体的信息建议落地到这三个文档中。业务流图文档只关注核心领域本身的领域对象(实体,属性,值对象,工厂,仓库,接口服务)以及核心领域与其他领域上下文的交互关系。
这三个文档的具体内容这里就不再详细展开了，下一篇文章将专门演示一些案例。

循环前面5步得到最优最全领域模型和业务时序

通过前面的几步我们基本上通过这个建模方法和业务流图得到了以下四个文档图:

领域模型文档
核心业务时序文档
整体业务时序文档
业务流图(总揽)

五、总结

需要特别说明的有以下几点

有时候我们的核心领域依赖的上下游太多，也比较杂，这样的话整体业务流图就会变得长很多，可以继续在业务流图中整理下或者突出角色标签来识别
每个业务流程的上下文中涉及到的业务实体其实可能都比较多，那么业务流图的纵深也会很宽，所以建议分多个画布来构建核心业务流程。
对于一些比较简单的业务实体或者配置可以不需要在业务流图中标注具体属性信息，在进行领域模型整理的时候则可以完善一下，同理简单的业务CURD也可以不需要在业务流图中展示。