设计思路-订单系统

在某团上，我们选中了一份猪脚饭，加入了购物车中，点击"去支付"，生成了一个待支付「外卖订单」，选中"微信支付"，生成了一笔待支付的[交易订单]，点击“确认支付”，生成了一个待送的[派送订单]...

随着电商，物流，外卖的攻城略地，订单的概念的好像在潜移默化了改变了我们的生活，不用的业务下衍生了不同的订单模型。拿电商来说，涉及实物订单模型，交易的订单模型，售后服务订单模型，分账订单模型等。

你会发现，各种各样的订单不同的组合，恰好就是代表不同的业务的执行过程，是为每一个过程的凭证，每一个订单的上的要素组合描述了要做的什么。

订单模型

上面已经说了不同的业务形态有不同的订单模型，如：

1. 标准零售业务模型

业务形态：一个典型的B2C（Business-to-Consumer）零售电商，如在线服装店。

• 订单模型特点：
• 简单结构
• 即时支付
• 快速履行
• 退换货政策

1. 表设计

订单表

订单ID	客户ID	订单状态	订单总价	支付方式	支付状态	订单日期	预计发货日期	实际发货日期	运输方式	运单号
唯一标识订单的编号	关联到客户资料的标识符	如待支付、已支付、配送中、已完成、已取消	订单的总金额	客户选择的支付方式，如信用卡、PayPal等	支付是否完成	单创建的日期和时间			选择的配送服务，如标准配送、加急配送等	物流公司提供的追踪编号

订单明细表

订单明细ID	订单ID	商品ID	购买数量	单价	小计
唯一标识订单中每个商品的编号	关联到订单主表的标识符				单个商品的总价

客户地址表

地址ID	客户ID	收货人姓名	收货地址	联系电话

2. 定制化生产业务模型

业务形态：一个B2B（Business-to-Business）公司，提供定制化的机械设备。

订单模型特点：

• 复杂结构
• 分阶段付款
• 长期履行周期
• 项目管理集成
• 售后服务

在这两种不同的业务形态中，订单模型的设计必须考虑到业务的特定需求。对于B2C零售电商，订单模型更加标准化和自动化，以便快速处理大量订单。而对于B2B定制化生产，订单模型则需要更多的灵活性和细节，以管理复杂的生产和支付流程。

状态机

订单系统的状态机（State Machine）是一个抽象模型，它用于表示订单在其生命周期中的所有可能状态以及在这些状态之间进行转换的事件和条件。状态机可以帮助开发者理解和管理订单流程的复杂性，确保订单的处理逻辑既清晰又一致。合理的状态机设计，应该能准确反应当前的业务状态。

一个订单系统的状态机通常包含以下几个关键组成部分：

1. 状态（States）：这些是订单可以处于的不同阶段，比如“待付款”、“已付款”、“处理中”、“已发货”、“已完成”、“已取消”等。
2. 事件（Events）：这些是导致订单从一个状态转移到另一个状态的动作或发生的事情，比如“支付成功”、“发货”、“取消订单”、“确认收货”等。
3. 转换（Transitions）：这些定义了在特定事件发生时，订单状态如何从一个状态移动到另一个状态。
4. 守卫条件（Guards）：在某些情况下，状态转换可能需要满足特定条件。这些条件被称为守卫条件，它们决定了是否可以进行状态转换。
5. 动作（Actions）：转换可能会触发一些动作，比如发送通知、更新库存、记录日志等。

要设计一个订单系统的状态机，你应该遵循以下步骤：

1. 定义状态：列出订单可能经历的所有状态。
2. 定义事件：确定哪些事件会触发状态之间的转换。
3. 设计转换：为每个事件定义从一个状态到另一个状态的转换规则。
4. 实施守卫条件：确保只有在满足特定条件时，才能进行状态转换。
5. 关联动作：确定在状态转换时需要执行哪些动作。
6. 绘制状态图：使用状态图可以帮助直观地展示状态、事件和转换之间的关系。
7. 实现状态机：在代码中实现状态机，可以使用状态机库或框架来简化这个过程。

在实际开发中，状态机的实现可以通过多种编程语言和框架来完成。例如，在Java中，你可以使用Spring State Machine；在JavaScript中，可以使用XState库；在Python中，可以使用Transitions库等。

以订单模型1举例，状态流转表示为：

拆分订单

拿双11的天猫的活动【跨店满200减30】的来说，就是拆单的最好案例，拆单一般有几种因素

1. 商家不同
2. 仓库不同（京东常见）
3. 品类不同（药品和生活用品）
4. 源头不同（海淘）
5. 附属单（京东家电会生成安装服务单，还有一些会生成赠品单）

拆单简单，但是里面的拆单规则不简单，涉及到库存，分类，物流状态等状态实时信息的判断，拆单的优惠分摊，售后也息息相关。

模型可以表示如下：

在三方支付中，充值，转账，提现，退款，分账等交易行为都可以视为一种订单，可见订单模型是存在于电商的每一个角落。

订单逆向

既然可以用订单抽象话业务正向流程，所以业务的逆向流程也是可以用订单来表示的。

相比正向流程的一环扣一环，退款是会出现在订单的正向流程的任何节点，逆向场景多，组成复杂是逆向流程复杂的原因。如果逆向需用正向流程来完成，复杂度会更高，例如退款不是原路退款，是赠送优惠券，或者用付款代替等。

用户参加双11的活动，跨店满200减30，现在用户甲申请退款/换货其中一件商品，逆向可能需要考虑：

• 退款金额计算：当退还涉及促销活动的商品时，退款金额的计算变得复杂。需要确定退款金额是否包含分摊的折扣额，以及如何公平地计算这一部分。
• 支付方式处理：如果客户使用了特定的支付方式（如信用卡或第三方支付平台），退款流程可能需要遵循特定的规则和时间框架。
• 库存重新调整：退货/换货可能涉及库存计算，需要保证库存数量实
• 财务和税务影响：退款可能会影响商家业务的收入和税务报告。必须确保财务记录准确反映退货和退款
• 平台规则控制: 平台规则的控制退款时间，或者风控控制等限制
• 关系系统处理：未收款退款，需物流系统及时调度，控制货物流程状态

订单的逆向，一般会单独作为一个退款服务模块，由业务，产品参与设计，开发结合正向订单结构，才会最终得出模型。 可以看退款中心设计