一、前言
电商零售作为微盟拳头 SaaS 产品，随着产品持续迭代，模块和模块间的耦合严重、改动牵一发动全身，新需求的迭代速度慢等问题凸显。为了更好地支撑零售 SaaS 业务，决定对整个电商零售进行端到端的重构，基于新的业务中台重新构建前端、后端和大数据，以期望破除系统的网状结构，形成大中台、敏捷前台的研发格局。

二、千禧方案

为了新云体系下电商零售业务完整迁移到 WOS 体系下，基于中台方案，制定了周密的迁移方案，从数据到业务，从产品到功能，完成了百分百迁移并完成 WOS 体系适配优化。

三、新云业务梳理

首先，协同产品团队梳理新云体系下微商城、智慧零售中售后业务能力和产品功能逻辑。

四、中台能力拆分

其次，协同中台团队，理解透彻新云实现方式，通过微服务化完成边界治理，抽象售后通用能力。以「申请售后」为例，我们将整个流程拆分为以下几个步骤：

序号	业务步骤	下沉中台	SPI扩展点
1	参数校验
2	查询订单和已有售后单	是
3	计算售后数量和金额	是	需要，业务自定义
4	计算活动等二级业务内容，并准备数据	是	需要，业务对接
5	校验是否可以售后	是	需要，业务自定义
6	准备售后单模型数据	是
7	创建售后单	是
8	设置创建后置处理和消息	是	需要，业务自定义
9	返回售后单
10	处理商城体系通用能力，比如：操作日志等

五、售后架构设计

在架构层面，结合迁禧方案，采用经典四层架构设计，划分业务和中台边界。在服务上，基于功能划分微服务，如下图：

服务	说明	备注
order-mgr	商家侧服务	用于B端、APP&企微端等所有商家侧操作的服务
order-web	用户侧服务	用于C端等所有用户侧操作的服务
rights-service	售后业务服务	用于对接中台能力，并结合商城业务处理的服务，包括中台扩展等
order-global	订单全局服务	用于对接非商城核心业务能力的服务
open-gateway	开放网关服务	用于对接微盟云，提供WOS开放能力的服务
open-adapter	开放桥接服务	用于对接微盟云，提供桥接新云开放能力的服务

六、售后模型设计

1.领域模型

对业务层领域（售后单（rightsInfo））内进行模型设计，拆分出以下主类：PS：细节可以参考微盟云。

2.售后生命周期

2.1 申请退款

2.2 申请退货

2.3 申请换货

七、售后关键流程设计

1.申请售后流程

申请售后是售后体系中最重要的一个流程，涉及到多个方面的信息逻辑和金额计算，目前通用能力已经下沉中台，站在商城的业务角度，对中台扩展点进行业务补充和适配，其中难度最大就是扩展点链路的编排。以下是一个简单的申请关键流程图，及其可自定义的 SPI 点。

2.售后审核流程

对售后审批的场景进行深度分析，可大致概括为三类：

• 无需第三方，直接操作同意或拒绝；
• 需要第三方审核，且审核通过后进入退款流程；
• 需要第三方审核，且存在多个第三方、有相互依赖，全部审核通过后进入退款流程。

综合以上场景，进行能力抽象和功能通用化，设计出「挂载节点」：

• 一种可以挂载在任一售后状态前后的处理节点；
• 可以有多个或先后顺序；
• 支持手动写入、单一触发和批量处理。

例如：申请时写入审核节点。

3.退换货售后流程

零售中，退换货是一种常见的售后场景。WOS 体系下，我们针对退换货售后，会新生成一笔换货订单，并集成原订单的相关资产和信息；且支持换货订单的二次售后。以下是退换货的主要流程：

八、结语

本文分别从微盟新 WOS 体系的产生背景、业务迁禧、中台售后划分、主要流程设计等几个方面介绍了微盟电商零售体系中售后业务的架构设计和开发思路。经过一年来的迭代和实践，商城售后业务系统已经完成了新云售后所有功能的转换和优化，并且完成了更多业务场景的支持。