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

前言

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

二.订单系统的详细设计

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的订单状态扭转

异常状态

异常状态分为 1.根据下游系统返回的信息而变更的异常状态。 2.订单管理系统主动操作导致的异常状态。异常状态在下游系统都是处于无法出库的状态，需要进行人工操作后，转化成中间状态或者终态

终态

终态则表示订单已经结束了，不能进行人工操作,订单不能进行任何数据变更。

---

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

订单管理系统会对接各种电商，无论是技术人员听过的，还是未听过，那我们经常需要快速对接各大平台的订单，同时兼容订单管理系统的内部逻辑，不应因为平台增加而改变原本稳定的系统，从而增加技术债务.

平台订单通过订单转化器转换成系统订单，当系统订单出库完成，需要进行物流上传时，通过平台工厂类反射生成对应的平台实现类，而每一个平台实现类都是相对独立的，当某个平台发生变化时，只需要修改对应的平台实现类即可，内部逻辑调用的抽象类提供的统一的对应接口，这样在新增平台时并不需要进行修改内部业务逻辑。

---

五.结语

拖拖拉拉写了半个月，这份总结总算写完了，比写代码难太多了，不知不觉也当了快7年的程序员，无论是业务层面还是代码层面，依旧觉得自己是管中窥豹，路漫漫其修远兮，吾将上下而求索。