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

前两篇文章向您展示了一种相对新颖的建模方法，但也是一个简单的实际战斗。在这里，我通过生活中的一个例子来模拟快递业务中的模型建设过程。本文将完全展示基于上下文的业务流程建设模式的操作过程。

事情的原因是我媳妇在家乡的生活把包裹邮寄到杭州。不幸的是，五个包裹中有两个重复了快递订单号，也就是说，我们只收到了四个快递到杭州作为用户。经过一系列的沟通，第五个快递运来了。当然，中间的快递体验有点差。毕竟里面有父母做的年货，容易坏。

当然，作为一名技术人员，我们必须知道这是一种异常情况，但重复运单号确实会产生一些业务问题。因此，如果我们在网上查看这种情况，最终的结果是很容易丢失快递。因此，我们不关心为什么快递运单号重复。相反，我们将看看如何通过基于上下文的业务流程建设模式构建快递物流模型。

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

1. 快递公司参与电子商务业务的商品邮寄业务)
2. 快递公司参与个人邮寄业务(私人)

在建模之前，我们将首先明确与角色相关的参与者和参与职责。

在这里，因为我没有从事快递业务的发展，我也咨询了相关的学生。这里只列出了一些过程的一般内容和快递拒绝场景。更详细的场景将更复杂，当然，更符合业务需求。

1. 正业务流程-个人快递业务

2. 正业务流程-电子商务公司快递业务

3. 逆向过程-快递拒收场景

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

此外，还有其他统一的快递业务语言，如上门、到付、退货等。由于篇幅有限，这里不再继续。

在这里，我们根据以上梳理的一般流程，结合以下业务流建模法的步骤，逐步构建快递公司的快递业务领域模型。

在这里，我们从快递公司的角度来看，快递业务的核心领域是什么？核心领域也意味着商业价值带来利润的领域，所以核心领域应该是基于快递衍生快递订单的快递。在这里，我们将快递订单作为订单领域，快递本身作为核心领域，然后查看其他统一语言背后的业务领域。因此，对于发件人来说，收件人也是基于快递货物的，这是业务流程的核心对象或上下文。但隐喻是，发件人必须是快递公司的用户，收件人不一定是。但如果收件人是，也就是说，发件人和收件人是系统用户，此时我们可以将发件人或可能的收件人用户视为用户的上下文或用户子领域。

另一方面，快递网点、快递员、快递中心与快递公司合作，所以从业务快递网点可以计算上下文，快递员工包括客户服务我们计算上下文，运输中心具有存储功能，也是大型物流中心的核心领域，快递公司需要依靠运输中心等机构在不同城市做业务，然后我们可以在仓库或仓库中上下文。

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