订单管理系统开发经验的总结:优化流程、提升效率的关键实践

前言

一.订单管理系统的架构设计

二.订单系统的详细设计

1.拆分

2.换货

3.发货

4.拦截

5.取消

6.物流回传

三.订单系统的订单状态流转

初始状态

中间状态

异常状态

终态

四.订单系统的关键代码逻辑

五.结语

前言

两年来，整个订单管理系统经过大大小小的重构，定下来了总体框架，系统也逐渐稳定下来，23年也快结束了，总结一下自己这两年的成果，顺便锻炼下文笔。

一.订单管理系统的架构设计

先简单介绍一下什么是订单管理系统，订单管理系统用于处理和跟踪销售订单的系统，涵盖从订单接收到订单履行的整个流程，我司由于是做跨境电商的，下面的场景都是基于国外平台的业务场景，在系统设计初期基于的原则便是高内聚，低耦合，强调的是可维护性与可重用性,通俗来说就是订单中心的逻辑尽量不做修改，灵活对接各大平台，适应各种业务场景。

我们系统主要承接了三部分的订单：第三方电商平台，toB订单，手工单，第三方电商平台主要是订单量较大的国外平台，例如亚马逊，shopify等，进行了平台API对接,对公订单是公司间购买发货的订单，对接了公司内部的TOB订单模块，手工单分两种1.是基于订单的补重改发，2.平台由于单量不够，还未到开发需要对接平台的量，创建对应的平台手工单进行发货

我们将未进入订单中心的订单称为SP订单，进入到订单中心的称为SO订单，SP订单进入到订单中心时，必定会有自己的平台归属

每个平台微服务都会定义一个平台订单转化器，把SP订单转化成标准的SO订单，在第一二版重构中，我们主要是规范了进入订单中心的标准字段，保证其通用性，第三次重构中，在重构中在转化器中定义了各种开关，对订单进行更加精细的控制，而不用对订单中心进行改动，比如是否需要物流地址校验，是否需要扣减库存等，这样在业务发生变动时，不用改动订单中心，只需要对平台微服务进行定制开发即可。

二.订单系统的详细设计

订单系统主要分为四个大表，分别为订单主表，订单明细表，包裹主表，包裹明细表

当订单进入到订单中心时，会生成一个包含所有订单明细的包裹并推送给下游业务系统，订单中心与下游发货系统通过包裹进行交互，订单系统通过包裹进行各种操作，包裹反向影响订单状态

1.拆分

一．平台订单进入到订单系统时，可能会生成包含多个sku的一个包裹，当某个sku暂时不需要发运时，则可以使用包裹拆分的功能，把不需要发货的sku拆分为一个新的包裹

二．当仓储系统发现某个sku暂时没有库存时，也可以使用拆分逻辑，把有库存的sku生成一个包裹先进行发运。

2.换货

换货操作一般发生在客服和客户共同协商需要更换货物，但是不需要重新下单的情况下，此时只要更换包裹内的sku即可，此时订单的sku不会发生变化，只会变更包裹明细的sku。

3.发货

包裹会继承订单的发运信息以及关键信息，并向下游系统发起创建出库请求

4.拦截

包裹向下游系统发起了出库请求后，客服进行拦截操作，则会向下游系统发起拦截请求，此时下游系统则会向第三方仓库发起取消（自营仓则判断是否出库，未出库则直接取消），然后作废本次的出库请求

5.取消

取消操作和拦截操作逻辑上是一样的，不过唯一不同的就是进行过取消操作的订单，无法再进行操作

6.物流回传

下游系统完成发货后，通知订单中心发货明细，订单中心通过发货明细中的sku再去通知对应的平台系统，完成平台履约

PS:订单中心和下游系统的一次出入库交互应该视为是一次完整请求，请求中应包含所有的出入库信息，两个系统之间相互独立，下游系统根据出入库请求参数即可完成一次出入库操作，下游系统不应中途再通过RPC，MQ等方式再去请求订单中心获取相关参数，以便后期的需求变动和防止下游系统和订单中心的过度耦合。

三.订单系统的订单状态流转

我们将系统订单状态分为初始状态，中间状态，异常状态,终态

初始状态

订单进入订单管理系统时最开始的状态，未生成包裹信息，在生成包裹信息时自动转换成中间状态，这个状态下，会根据平台订单状态进行更新变更

中间状态

订单生成包裹后，推送给下游系统，下游系统未返回处理信息或者返回部分发货时，订单会处于这个状态，中间状态最终会流转成异常状态或者终态，中间状态的订单不再依据平台订单状态而改变，例如订单A处于待发货状态，平台上面变成已完成，则订单A在订单管理系统还是待发货状态，由下游系统决定订单A的订单状态扭转