2. 从当前业务场景来看
由于笔者所负责产品主要面向便利店客户，进行美团等平台的O2O业务，即要求3-5公里范围内的即时配送，不涉及商城、跨境等业务。那么在当前的业务下存在三个配送场景：
- 平台配送：店员拣货后，通知外卖平台已拣货，平台会按照合同约定呼叫骑手配送；
- 商家自送：店员拣货后，店员自行将货物配送到顾客手中；
- 聚合物流：店员拣货后，OMS系统呼叫第三方承运商进行配送。
虽然有所差异，但是我们应该认识到本质都是发生在零售商和终端用户之间的交付流程，可以抽象成一个用例，如图所示：
那么方案范围中，需要统一管理这三种业务场景。
3. 从“三流”来看
在物流配送过程中，会发生了位置的移动，信息的流动和资金的流动。不同的场景下，物流、资金流、信息流的表现略有不同，如图所示:
当我们对三个流进行管理过程中，也提出了对方案范围的要求：
- 对信息流管理：通过接口调用，实现配送状态、配送位置、配送员信息等数据在多个系统间的一致性；
- 对物流进行管理：承运商的调度、支持商家自送订单发货、签收等功能、配送范围的划定；
- 对资金流进行管理：上文说到盈利模式，从ROI考虑，我们最终选择了使用功能直接付费的方式进行盈利，即在商家呼叫第三方物流的时候，商家直接与承运商进行结算，不通过4PL系统。
故：
- 在平台呼叫配送的场景下，顾客支付运费直接结算给外卖平台，同时外卖平台收取商家的履约服务费，在订单收入结算给商家时，已进行了扣除；
- 在商家自送的场景下，顾客支付的运费通过外卖平台结算给商家；
- 在商家呼叫第三方物流的情况下，顾客支付运费通过外卖平台结算给商家，商家再和承运商结算。
我们可以发现，不同配送场景切换时，需要注意资金数据的变更，以免出现财务对账问题。
五、领域模型的设计从实际业务来看，一笔订单由于拆单，可能会由多个门店发货，或者由一个门店多次发货，故订单和发货单的关系是一对多的关系。一笔发货单，可能尝试由多个承运商依次发货，故发货单和配送单的关系，也是一对多的关系。
4PL系统中，一个很重要的点，就是当其他承运商异常无法配送时，要使用其他承运商继续配送。为什么配送失败了，要重新搞一个实例，而不是用原来的呢？原因如下：
如第一个承运商长时间无骑手接单，此时4PL系统需要调用接口取消该承运商的配送，重新呼叫其他承运商。但是由于取消配送是异步交互的，需要等待承运商系统返回取消成功的消息，也有可能取消失败，需要重复取消申请，我在任务中心的设计《我对B端任务中心功能的设计思考 | 人人都是产品经理 (woshipm.com)》也说明了这个情况。
也就是说该配送单无法到已取消的状态，那么如果该配送单直接更新成其他承运商的数据，系统就不方便进行重试取消的操作了，因为没有业务单据承载这个动作了。
从普遍的设计经验来看，也有以下原因：
- B端日志需要进行详细记录，一个状态是因为什么发生改变的，什么时候改变的，往往是后续进行问题分析的一手资料，故不能覆盖；
- 遵循状态可逆原则。状态可逆后，造成的问题很多，在供应链领域，一个单据往往是线性发展的，而不像OA系统的单据，可能往往是需要反复确认反复调整的；
- 各平台的收费机制不同：配送单，是OMS系统发货用例的输出物，以及TMS系统的输入物，由于tms系统中，对应输入物还存在，那么上游系统中对应的输出物就应该存在，否则进行财务对账时，则凭证不对应。
一般来说，配送单的状态机设计如下：
