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

一、背景

前面两篇文章已经给大家展示了一个相对新颖的建模方法，也简单实战了下，这里我通过一个生活中的例子来模拟快递业务中的模型构建过程，本篇将完整的展示一下基于上下文的业务流建模法的操作过程。

事情的起因是我媳妇儿在老家的生活往杭州这边邮寄包裹，不巧的是5个包裹中有两个快递运单号重复了，也就是说5个快递运到杭州这边实际作为用户的我们只收到了4个。经过一系列沟通后第五个快递才运过来，当然，这中间的快递体验也是有点差的，毕竟里面有父母给弄的年货，容易坏掉。

当然作为技术人肯定知道这个是异常情况，但是运单号重复也确实会产生一些业务问题，所以从网上查了这种情况，最终的结果就是很容易丢失快递。所以这里我们先不关注为啥快递运单号重复的问题。而是看一下如何通过基于上下文的业务流建模法来构建一个快递物流模型。

二、基于快递物流领域的建模案例

2.1 需求说明(模拟各大快递物流公司运营场景)

这里快递业务场景实际上有很多，比如是电商类的快递，个人邮寄类的快递。大型货运快递或者航运快递等等。
所以我们这里就模拟最常见的两种情况

快递公司参与电商业务的商品邮寄业务（对公）
快递公司参与个人邮寄业务（对私）

2.2 角色参与

在建模之前我们先明确一下角色相关的参与人和相关参与职责。

角色名称	角色职责	说明
发件人	快递发送的动作执行人	商家，个人，公司
快递公司	负责快递收揽，发送，到收件人签收的整体业务过程管理	快递公司是整个业务流程系统数据的维护者
收件人	快递收货和签收的动作执行人	商家，个人，公司
快递员	负责快递揽收和快递运送到收货人	快递员负责联通快递物品，发件人收件人
快递站点	负责将快件从发件人手中发给快递公司，
负责将快件从快递公司发给收件人	快递站点负责区域快递业务，同时负责沟通发件人和收件人
快递转运中心	负责快递在不同城市转运，不同于仓库，转运中心的快递不长时间保存维护快件	不同城市不同区域有不同的转运中心来承接路程比较长的快件

2.3 业务流程串连

这里因为我本人没有从事过快递业务的开发，所以也咨询了相关同学，这里仅仅列出大致的一些正向流程的内容和快递拒收场景，更多细致的场景在时序图中体现会更加复杂，当然也更加符合业务需求。

正向业务流程-个人快递业务
正向业务流程-电商公司快递业务

逆向流程-快递拒收场景

2.4 统一语言与隐喻

我们从上面的小节中可以看到如果从统一语言的角度来看这里可以列出一些统一语言和隐喻相关的词语来帮助我们更好的理解业务，辅助建模，如下表，是统计的快递物流业务相关的统一语言:

统一语言词语	隐喻	说明
顺丰	顺丰快递公司	快递平台公司，顺丰为简称
韵达	韵达快递公司	快递平台公司，韵达为简称
EMS	邮政特快专递服务	国内为中国邮政快递公司，EMS为简称
快递，快件	快递的物品或者商品	这里的快递算名词，快件算隐喻或者快递业务的专用词
快递站点	快递公司与各个城市小区合作的快递网点，也叫快递网点	快递站点也叫快递网点，负责辐射区域范围内的快递收发业务，按类型有专门合作的快递，也有支持不同快递公司的快递业务
发件人	快递的发货方也是发件方	发件人一般按业务类型分为个人和公司或者企业
收件人	快递的收货方也是收件方	收件人一般按业务类型分为个人和公司或者企业
快递员	快递公司员工	负责收揽快递并将快递发送到收件人手里
转运中心	大型物流处理仓库	长途快递运输集中收发调度中心
快递订单	邮寄快递的凭证	类似于商品订单，记录快递需要的核心信息
签收	快递送达	快递签收意味着快递订单正常结束，一般情况下也存在快递员与收件人协调存放地点后自动签收
拒签	收货人拒绝签收快递	拒签也意味着一种快递订单异常结束的情况，需要相关方说明拒签原因和后续快递处理事项
运单号	快递订单的单据号	运单号代表一次或者一个快递订单

另外还有一些快递业务的其他统一语言，比如上门，到付，退货等等。限于篇幅原因这里不再继续展开。

三、建模过程

这里我们根据上面梳理的大致流程结合基于上下文的业务流建模法的步骤来逐步构建快递公司的快递业务领域模型。

3.1 识别领域上下文

这里我们从快递公司的视角来看一下快递业务的相关上下文有哪些，核心领域是什么？核心领域也意味着是产生商业价值带来利润的领域，所以核心领域应该是快递，基于快递衍生出快递订单。那这里我们先把快递订单当作订单领域，把快递本身当作核心领域，然后看一下其他统一语言背后代表的业务领域内容。所以对于发件人，收件人也是基于快递货物的，这里算是业务流程中的核心对象或者上下文。但是其中的隐喻是发件人一定是快递公司的用户，收件人不一定是。但是如果收件人是那就是说发件人和收件人都是系统的用户，而此时我们可以把发件人或者可能存在的收件人用户当作用户上下文或者用户子领域。

另外一方面快递网点，快递员，与转运中心都与快递公司有合作，那么这里从业务上分快递网点可以算一个上下文，快递员理论上算快递公司的员工包括客服这里我们算一个上下文，转运中心具有仓储的一些功能，也是大型物流中心的核心领域，快递公司需要依赖转运中心这样的机构在不同的城市做业务，那我们可以把仓储或者仓库当中一个上下文。

同时在长途物流过程中会涉及到大型货车的运输转运，这里在快递业务中对于参与的角色来说大型货车和司机其实存在感不强，按照现实场景来一般也有合作运输车队也有快递公司自己的运输车队。所以这个合作关系或者物流车队我们在建模过程中可能需要单独作为一个上下文来看，避免建模过程中遗漏。当然，如果我们不关注这个领域也无可厚非，毕竟我们需要关注核心领域和一些比较明显的领域上下文，在建模过程中可以随时调整增加这个领域来完善整个快递业务的业务模型。

现在我们先按基本的推演和识别结果画一下领域上下文图。当然如果在团队中可以每一个人都出一份然后共同讨论出最合适的领域上下文图，将其当作第一步的建模结果。这里我们先给出一个粗略的领域上下文图，具体则可以相对详细的给出每个领域的核心对象，后续会继续丰富整个业务流程模型。

注：这里在第一步即可将领域上下文图和上下文之间的大概关系梳理出来，所以可以把构建领域上下文的上下游关系这一步给去掉。

3.2 创建画布

这里我们构建一个比较宽的画布，然后分领域服务和上下文，通过标红的框来识别核心领域内容。这个画布的作用类似于一种大纲或者草稿，从这里开始我们可以基于这个画布来构建相对详细的业务流模型。

3.3 建模

这一步需要花费的时间会比较多，我在构建画布中的内容时也做了多次调整，看上去很简单，但是不懂业务或者没做过则会难一点。还是之前的套路，我们将画布分为三个部分，然后分别填充不同的内容。

3.4 归纳推演

在这一步中我们可以针对不同的用户故事来补充和调整不同的实体所处的上下文，同时补充对应的角色和实体的属性。然后不断完善基于不同用例场景的建模字段和业务语意。当然涉及到相对关键的地方也可以通过UML类图来对某个上下文的业务操作流程进行详细展开，这样可以快速得到一个业务组件的基本模型，只不过这里的UML类图文档可能就不在业务流图中展示了。

3.5 整理沉淀

这一步可以具体消化下上面的业务流图中的内容，我们可以构建一个相对完整的领域模型，如下图：

这里我们看一下简单归纳总结之后的数据库e-r图：

由于上面的是业务流图，所以可以抽取业务用例，作为用例图或者用户故事。另外一方面需求文档上也会有一些泳道图之类的需求说明，可以将需求文档与业务流图结合起来构建业务调用时序图。这里我们如果深入模块或者服务组件级别则可能需要从技术的角度来画一下业务操作是从哪个端发起的，中间经历哪些服务的哪些层，然后其他端如何与系统交互完成整个业务操作。这里也简单给一下业务时序图，仅供参考:

3.6 不断优化

通过上面的建模过程，我们最终得到了很多我们想要的文档，而且这些文档可以作为系统的基石存在，所以不管是从0-1建设的需求还是迭代式的需求这些文档都将是软件系统的宝贵财富，需求不断变化，所以这些文档也会有一些变化。
通过不断的维护和优化文档模型我们最终会得到一个当前系统的相对客观的业务模型和业务流程。所以这个过程也需要体现在建模方法中，不是用了一次建模方法后续就不需要了。

3.7 落地建模

这一步是可选操作，因为前面的建模内容都可以认为是技术讨论，方案和模型设计环节，所以算是编码前的一些设计准备，那么在落地建模的时候我们就可以将模型落实到代码上来看看是否符合预期，当然更多的不止于模型，还有一些别的代码，所以如果要快速验证代码内容还是需要团队和相应的工具的。这里推荐一下天画-codeMaker,支持将领域模型UML文档转换成代码，如果有数据库e-r图模型的话则可以支持后端低代码生成：
天画的开源gitee地址是：https://gitee.com/sky-painting/code-maker
另外关于建模相关的文档资料都会在上面这个工程和另外一个DDDinaction的gitee项目中，可以关注下，开源地址如下：
https://gitee.com/codergit.com/dddin-action

四、总结

本篇基于一个现实场景的行业建模来演示一下基于上下文的业务流建模法的操作过程，当然整个建模方法还需要一些改良，欢迎有需要用到建模的地方使用该方法一起改进。
另外上一篇文章的微信公众号图片不够清晰，这里放出原版文章链接，方便串联整个建模方法的内容：
https://www.yuque.com/docs/share/eb019d37-bf5e-40d1-95e3-2b208c8c82d0?# 《基于上下文的业务流建模法(二)》