📚 课程目录第4章订单模型设计

4. 订单模型设计

在聚合支付对账平台中，订单模型是连接交易、清算、对账与差错处理的核心数据载体。一个设计良好的订单模型，必须同时满足业务语义完整、状态流转可追溯、扩展灵活三大目标。本节从统一订单模型、状态机、生命周期与扩展字段四个维度展开。

4.1 统一订单模型

统一订单模型将支付网关、渠道、商户、用户等多个视角的订单信息合并为一个标准结构，消除数据孤岛。核心字段分为以下五组：

分组	字段示例	说明
订单标识	order_id, merchant_order_no, channel_order_no	全局唯一ID、商户侧单号、渠道侧单号
金额与币种	total_amount, pay_amount, refund_amount, currency	总金额、实付金额、已退款金额，单位分
参与方	payer_id, payee_id, merchant_id, channel_id	付款方、收款方、商户、渠道标识
时间戳	created_at, paid_at, settled_at, reconciled_at	关键事件时间，用于对账窗口计算
对账状态	reconcile_status, diff_type, last_diff_id	对账结果标记，关联差异记录

设计要点：统一订单模型应避免将渠道特有字段平铺到主表，而是通过扩展字段或关联表承载，保持核心结构的稳定与简洁。

4.2 订单状态机

订单状态机定义了订单从创建到终态的合法流转路径。对账平台关注的状态机不仅包含支付状态，还包含对账与清算状态。以下为典型状态机设计：

  状态机约束：
  不允许从“支付成功”回退到“支付中”或“待支付”。
“对账一致”与“对账差异”为互斥终态，不可同时存在。
“已结算”状态仅能从“对账一致”或“已调账”进入。

4.3 订单生命周期管理

订单生命周期管理关注订单从创建到归档的全过程，包括事件记录、超时处理与归档策略。以下为生命周期各阶段的关键动作：

阶段	触发条件	关键动作	超时处理
创建	用户提交支付请求	生成订单ID、记录创建时间、写入事件日志	—
支付处理	渠道异步通知或轮询	更新支付状态、记录渠道返回码	30分钟未支付则自动关闭
对账	日切后定时任务触发	比对平台与渠道数据、生成对账结果	T+1日未对账则标记为待处理
差异处理	对账结果不一致	创建差异记录、通知运营介入	48小时未处理则升级告警
结算	对账一致或调账完成	生成结算单、更新结算状态	—
归档	结算完成超过90天	迁移至历史表、清理缓存	—

注意：生命周期管理必须记录每个状态变更的时间戳与操作人，以便对账差异排查时进行时间线回溯。建议使用事件溯源（Event Sourcing）模式存储订单事件流。

4.4 订单扩展字段设计

扩展字段用于承载不同渠道、不同业务场景下的差异化信息，避免频繁修改订单主表结构。推荐以下三种设计模式：

JSON 扩展字段：在订单主表中增加一个 extra_info 字段，类型为 JSON 或 JSONB。适用于字段不固定、查询频率低的场景。
扩展属性表：设计独立的 order_extension 表，使用 key-value 结构存储。适用于需要索引查询的扩展属性。
渠道专属子表：为每个渠道创建独立的扩展子表，通过 order_id 关联。适用于渠道特有字段多且查询频繁的场景。

-- 示例：JSON 扩展字段设计
CREATE TABLE payment_order (
    order_id          VARCHAR(64) PRIMARY KEY,
    merchant_order_no VARCHAR(128),
    total_amount      BIGINT,
    pay_amount        BIGINT,
    currency          VARCHAR(3),
    status            VARCHAR(32),
    reconcile_status  VARCHAR(32),
    created_at        TIMESTAMP,
    paid_at           TIMESTAMP,
    extra_info        JSONB,  -- 扩展字段
    created_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at        TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 示例：扩展属性表设计
CREATE TABLE order_extension (
    id          BIGSERIAL PRIMARY KEY,
    order_id    VARCHAR(64) NOT NULL,
    attr_key    VARCHAR(128) NOT NULL,
    attr_value  TEXT,
    created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (order_id, attr_key)
);

推荐实践：对于对账平台，建议采用 JSON 扩展字段 + 关键字段索引的方式。将对账所需的渠道流水号、渠道返回码、对账时间等高频字段提取为独立列，其余业务扩展信息放入 JSON 字段，兼顾查询性能与扩展灵活性。

4.5 模型验证要点

在测试验证阶段，需重点覆盖以下场景：

状态机路径覆盖：验证所有合法流转路径与非法路径是否被正确拦截。
扩展字段读写：验证 JSON 字段的序列化/反序列化正确性，以及超长文本的截断处理。
生命周期超时：模拟超时场景，验证自动关闭、告警升级等逻辑是否按时触发。
并发安全：验证同一订单在并发状态更新时不会出现状态覆盖或数据不一致。

通过以上设计，订单模型能够为对账平台提供稳定、可扩展、可追溯的数据基础，支撑后续的对账引擎与差异处理模块高效运行。