订单系统发展历史
- 1.订单系统中包含 购物车管理、下单、活动玩法价格计算，C端的订单管理，订单支付后的各种通知；
- 2.购物车、以及服务于订单的活动玩法系统等从订单中拆分出去，成为两个独立的项目(cart、activity)；
- 3.交易下单（渲染订单、提交订单）独立出来，成立专门的trade服务、和处理C端订单管理、支付后订单状态的流转区分开，让下单独享机器性能；
- 4.下单失败，需要同步对于预扣的资源做各种回滚处理，延长接口耗时影响用户体验，对于性能有一定损耗，将回滚逻辑从trade移除，交由分布式事务中间件tccService来管理回滚，进一步提升性能。
重构的由来
使用责任链来组织业务逻辑，编写代码
public interface Processor {
/**
* 每一个Processor里的子类都会去改变order对象,不断的丰富Order对象的数据
* 同时根据不同的业务类型(submitOrder,renderOrder)去丰富不同的result
* @param request
* @param result
* @param order
* @return
* @throws ServiceException
*/
void process(OrderRequest request, BaseResult result, Order order) throws ServiceException;
}
像用户的基本信息，地址信息，vip信息，商品信息，价格信息，库存信息，玩法信息，用户优惠券，用户积分等信息的获取校验，以及订单金额、折扣计算、消费第三方数据，保存订单，都会放到Processor中处理
缺点是：随着玩法越来越多（比如限时特惠、营销三宝、闪购、众筹、拼团、砍价、预售、超级团等等），而规则也逐渐复杂，比如，限制用券、用积分、不扣库存、满足某玩法的spu不能享受vip折扣、不发放积分、两阶段付款的在第一阶段不校验用户地址等等。当初设计采用这种模式时，还在玩法迭代初期，为了方便灵活，所以扩展点在Processor的增加，导致Processor急剧，而且Processor处理的过程中用到的判断数据，来自于requst和result，而经过多个processor后，result属性会发生多次改变，参数发生耦合复用，导致出现了不少bug，而且每次上线一个新玩法需求，需要测试进行全量回归，涉及下单流程这条线的研发和测试苦不堪言。基于上述情况，决心进行重构一把。
梳理场景
从这么多玩法迭代来看，其实下单涉及到几个关键流程
- 基础数据加载并校验（包括用户、商品、玩法、能不能用券、发券、用积分、发积分、享受vip资格、取消订单时间等等）
- 计算商品折扣
- sku拆分（方便用户明了折扣明细、以及发起退款rma）
- 消费第三方数据（包括优惠券、积分、玩法资格：比如闪购资格）
- 订单落库
- 通知第三方系统（通知购物车清除刚购买商品、搜索更新商品销量排名、消息系统发推送提醒付款等等）
实施
- 定义配置类，存储玩法规则，等等各种基础信息
- 依赖配置类，开发各个业务逻辑模板
- 下单时，通过配置加载器，调用玩法服务加载并组装配置信息，同时，商品的折扣信息，可以提前到调用玩法系统时就能确定，由玩法系统计算好，存入配置即可，根据配置进行下单链路的动态调用
总结
- 1.提高了trade服务的稳定性，因为预留拓展点：TradeActivityGroupLoader、IValidator：可以做到新增玩法，在玩法系统开发实现一个数据加载器，组装好玩法需要的配置数据，实现一个校验IValidator放进校验类集合中，订单只需要简单接入这个数据加载器，就能让新玩法工作，解耦性比较好，达到在下单逻辑组件少改甚至无改动，因为改动都在玩法系统，也减少了测试的回滚范围，bug率显著下降；
- 2.提升了下单性能，因为将一部分逻辑从系统中迁移出去（包括玩法折扣的计算，玩法基础信息的校验下层到玩法系统来计算）
附件资源：UML图
交易商品信息
数据容器
交易活动组信息
下单活动图
下单时序图
时序讲解：
- 根据ActionType决定bizType（例如拼团商品单独购买，是没办反根据商品有拼团这个Indicator来决定bizType的）
- 根据入参获取订单流程的基本信息，包括获取用户的基本信息，地址信息，vip信息，商品信息，价格信息，库存信息，玩法信息，用户优惠券，用户积分信息
- 其中对于商品信息，如果是定制商品，则直接进行拆分
- 该对象是只读的，在构建完毕只提供只读接口
- 这里有几个设计考量：
- 根据不同的ActionType决定要不要load 优惠券积分
- 根据业务系统构建的ActivityGroup来决定要不要load 优惠券积分
- 一次性load所有数据，根据业务类型，在内存里面做过滤 ，目前实现选用3方案，原因是，性能上有损耗（但是是可控的），但是设计上会更合理
- 如果bizType是normal（ActionType是直购或者购物车购买的话），则尝试通过商品Indicator里决定bizType，例如都是直接购买，购买一个众筹商品和购买一个拍卖商品，bizTye就是不一样的
- 校验SKU信息（库存，上下架，如果是submit阶段，则直接抛异常）
- 根据bizType调用不同的业务系统构建TradeActivityGroup
- 根据TradeActivityGroup获取活动商品分组，折扣信息，进行SKU拆分
- 计算优惠券 积分折扣 门店折扣
- 计算订单金额
- 比较计算得到的价格是否和用户提交过来的价格一致
- 消费第三方数据（消费优惠券 消费积分 扣减库存）
- 保存订单
- 通知第三方系统
