简单介绍
在2024年8月份开发了商城小程序微信版系统，当时是单体项目，我主要做了支付，订单是其他人设计的。而今年2月份开年商品从单体改为分布式，因为是小公司，我这个项目组后端一共4个人，我自己由于之前做了支付，这里订单这块就都交给我自己弄😄，做了很多，改了很多次，刚开始求速度，简单分析了一下就开始写代码。
代码弄的有点惨，这里开始理清自己的订单模块，首先说一下，该系统并发量很低，公司项目就不说了。
- 公司刚开始是订单20分钟过期，后面因为客户，订单变为了永不过期,因此将mq+定时取消（补偿）这块干掉了
- 公司订单又分很多类，不同类不能同时下单，就是说一个订单下的商品都是一类的
- 公司商品的价格跟地区挂钩，动态设置，不同地区价格不同
- 我们项目的积分商品只能通过积分兑换，不存在积分不足，加钱的情况
- 因为对接的微信，微信至少付1毛，可以简单将订单分为3份，1--免费订单（优惠劵金额 >= 所有商品的支付金额），2-积分订单，3--订单的支付金额>0的订单（优惠劵金额 < 所有商品的支付金额）
明确设计
虽然修改了几次，最终采用的是状态机+策略的方式，通过发布不同事件，每种订单执行自己的事件处理 1类订单和2类订单不会走微信接口，3类订单才会走微信接口。
果然独立开发,没人打扰，想怎么弄就怎么弄
状态
- 订单状态：取消、下单、支付、发货、收货、完成
- 配送单状态：待配送、配送中、配送完成
- 售后单状态：售后中，售后通过，售后驳回
- 事件: 支付成功事件、支付取消事件、发货事件、收货事件、售后申请事件、售后通过事件、售后驳回事件
系统是将订单状态和售后状态进行区分，这种可以知道售后之前的订单状态
下单设计
用户下单会选择商品，地址，以及优惠劵以及其他业务的处理；这里选择下单的时候生成一条预支付订单，该订单用户感知不到，用户选择地址、优惠劵，或者其他会影响订单的操作等等每次都会请求后端修改预支付订单的信息 ；优惠卷状态，地址判断，金额等等都提前处理好，后端计算，前端显示，减少支付接口的功能，做到接口单一性原则，支付接口只需要修改预支付单为支付单，走支付流程即可
支付设计
对订单进行支付有两种情况：1.不存在支付单号，2.存在支付单号
1.不存在支付单号--直接生成支付单号，调微信接口支付即可
2.存在支付单号--就要先请求微信查询接口
- 没有数据，使用该单号未进行支付
- 存在数据，但是订单未支付，我是直接请求微信接口关闭订单，生成新的支付单号，然后支付
- 存在数据，订单已支付，返回提示并异步走支付成功的流程
订单支付后的状态是通过微信回调修改的，但是积分订单和免费订单是没有走微信接口，没有回调，所以系统内部模拟一条回调
取消设计
订单取消分为两种情况：1.存在支付单号，2.不存在支付单号
1.不存在支付单号--直接取消订单即可
2.存在支付单号--就要先请求微信查询接口
- 没有数据，使用该单号未进行支付，取消订单
- 存在数据，但是订单未支付，我是直接请求微信接口关闭订单，然后取消订单
- 存在数据，订单已支付，返回提示并异步走支付成功的流程
最终流程图
我用亿图图录画的图，好像有点大，展示不出来
对于我这家小公司项目够了
