前言
在电商系统中，订单系统往往承载着非常重要的角色。在极光商城项目的准备阶段，最耗费我时长的就是订单系统了（毕竟实力也不咋样😅。这期间我也查阅了大量资料，为这一块的设计做了些准备。只能说第一次设计，还是挺想做出个好东西来，但是这要考虑的东西，可比单纯的写业务代码要多得多了呀。
业务关系
订单系统
先来看看订单系统在整个极光商城中扮演的角色，实际上是负责管理平台交易的订单处理系统。
订单管理
订单管理模块，主要的体现就是在后台的订单管理模块了。主要功能为订单列表、订单详情、订单定时任务、订单操作、订单跟踪、订单售后、订单流水等。
订单服务
订单服务模块，为整个商城的业务支撑，负责的业务也是较复杂的。主要有订单创建，订单支付、订单确认、取消订单、发起售后、订单跟踪等流程。其中的规则较为复杂，比如说在用户提交订单时，得根据相应的规则判断订单是否合法，也可以理解为风控吧。然后要计算订单的金额，购买了东西，相应的库存也要变化，还要考虑超卖问题。其中某些步骤可能是需要异步调用的，举个例子：我用12306买票时，付款后，先收到邮件，然后12306APP这边的状态过几秒钟能看到购买成功，这里发邮件的功能，可能就是用的异步调用。
订单信息
整个订单的设计，是采取的主表和子表。主表主要会存放订单的基本信息、用户信息、订单流水，物流信息、促销信息、等。但是考虑到一个订单可能包含多个商品，所以说子订单就是用来存放这些不同商品的信息的，当然，也可以进行订单拆分业务，但是即使这么设计，也要考虑到用户只应该付一次款的问题。
数据库设计
数据库里面，目前只对订单系统设计了6张表，以目前的业务来看的话，是绰绰有余了，以后业务变更了再修改吧。
订单流程
就以正常下单的流程来说吧，售后的订单这里就不过多介绍了。
订单创建
用户登录商城，挑选想要购买的商品，然后选择地址和促销信息并提交订单。然后生成订单前，我们需要获取用户信息、商品信息、促销信息等。当然，并不是所有的数据都从前端接收的，不然的话用户传个假的价格过来，岂不是0元购了😂。获取完信息后，这时后台的风控系统，可以进行一系列的规则校验。咱们还得判断库存吧，库存不够了也不能卖，这里的业务设计，以提交订单为准进行库存的扣除。最后生成订单信息和支付信息，同步当前订单即创建完成。
订单支付
支付的话，肯定就是对接第三方平台做一个支付功能了，具体的可以去看支付宝开放平台的文档做个参考。这里主要阐述下订单拆分问题。根据订单里面的商品的性质等原因，可以进行不同的订单拆分。但是，订单建议设计成同时支付和绑定订单。不然的话，很容易被凑单，从而造成一定的损失。除非你的业务就是想弄成淘宝那种，为了凑单拼到300元，然后付款了秒退凑单商品，从而达到优惠的效果。最后根据订单支付的结果，对订单进行操作，成功了就走订单生产流程，失败了就走失败订单的流程，还原被扣除的库存。
订单生产
如果有多个仓库，可根据用户收货地址等因素来调配仓库的货物。并将商品打包寄出，同时更新快递状态实时同步。
订单完成
用户收到商品后，确认收货，订单至此完成。
用户体验
在订单的整个生命周期，都可以通过消息队列来异步操作。比如订单状态更新了，可以给用户发邮件或者短信通知，在商城系统的用户中心也可以推送通知等。
最后
将订单系统进行拆分，也就是订单的管理和订单的处理这两个模块是分开的。主要是考虑到用户下单，和客服进行订单管理的业务区别有点大，前者操作很频繁，后者可能更多的只是看看，做的操作较少。虽然移动端我现在还不会开发，但是得想到一个问题，不同的平台，对应的订单系统的处理逻辑肯定无法保证100%相同的。那么将逻辑拆分，统一管理，我觉得可能是较好的一个方案（目前也只能想到这一步了😅），脚踏实地，一步步来吧，毕竟自己要学的东西也很多。
大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。
《大型网站技术架构：核心原理与案例分析》——李智慧