业务系统重构总结

之前在服务化设计模式实践(http://blog.brucefeng.info/post/service-design-patterns-practices)里面介绍了交易侧系统服务变迁的模式，服务的变迁更好的支持了业务的发展，伴随着业务的发展，对业务系统内部的要求也更好，需要具有更好的扩展性。随着业务的不断发展，每个服务内部的逻辑也变得越来越多，需要有更好的抽象来支持以后更多的业务类型。

1. 项目业务背景

重构的项目有订单服务，预订系统，退款系统；这三个系统都是与用户交易行为息息相关。

其中订单系统参与重构的模块为订单创建，订单状态流转，订单支付；

预订系统的重构主要为了支撑更多的预订方式，如之前已经支持的库存模式、商家接单模式和售中客服模式，伴随着重构还需要支持商家系统直连模式，而且需要能够支持以后业务发展更多的预订模式。

退款服务的复杂度主要来源于多种退款类型，如用户退款，系统退款，商家退款和客服退款等多种类型，而每种类型又有各种不同的退款规则；退款服务需要支持多种业务，如已有的KTV预订和将要扩展出的酒水点单。

在这里我们主要来讲讲预订系统重构，因为这个系统的重构几乎涵盖了订单服务和退款服务重构所使用到的技术

目标

抽象预订流程，并模板化

对可变化的部分支持配置化

在上线过程中支持新老流程切换

2. 业务抽象

由图中可以看出，业务流程非常复杂，一个订单的预订过程会根据不同的情况走不同的预订渠道，如果一个预订渠道因为某种原因预订失败了，可能会继续使用另外一个预订渠道继续进行预订，也就是会发生流转。

另外，在预订成功和预订失败时，会需要做一些其他操作，例如发送短信告知用户结果等；

图中还有一点没有体现的是，在开始发起预订时，需要校验数据的正确性，校验是否复核预订规则等等校验。

根据这些条件我们做了以下抽象：

首先订单从预订开始、预订中到预订成功/失败定义为预订的主流程，其中每个接单都是一个重要的业务节点，这种主流程定义为一级业务。

对于不同的预订模式(如库存模式、商家接单模式、客服售中介入模式和商家系统直连等)，抽象为预订渠道。预订渠道之前的转化定义为渠道流转。