支付账务与订单架构：从资金链路到领域边界
这篇把简历、千米工作材料和早期金融项目经验整理成支付账务方向的知识页。它的重点不是列项目，而是抽象出交易系统里长期有效的判断。
核心问题
订单、支付和账务经常被放在一起讨论，但它们不是同一个领域。
- 订单表达交易意图、商品明细、买卖双方和履约状态。
- 支付表达支付方式、支付通道、支付动作和支付结果。
- 收款表达资金确认、应收核销、实收归集和财务视角。
- 账务表达资金账户、清结算、对账、差错处理和可审计流水。
如果这些边界没有拆清楚，系统会很快走向“订单服务吞掉一切”：算费、称重、履约、支付、退款、对账、财务和运营查询都堆进同一个上下文里。
支付单、收款单和订单
工作笔记里有一个简洁判断：
- 支付单承载信息流。
- 收款单承载信息流和资金流。
这个判断可以继续展开：支付动作不等于资金归集，支付成功也不等于账务完成。支付通道返回的是外部动作结果，收款和账务要把这个结果放进企业自己的财务事实里。
因此，“订单即应收、支付即实收”是一个重要分界。订单生成的是应收依据；支付和收款确认的是实收事实；账务系统负责把这些事实变成可对账、可追溯、可核销的流水。
千米订单重构经验
千米时期的订单材料里，核心矛盾是业务快速扩张后，订单服务逐渐承担了过多职责：
- 分销订单、市场订单、采购链路和财务结算的代码大量重复。
- MQ consumer 和 callback service 仍偏过程驱动，Event Driven 没有贯彻到底。
- 分布式 ID、分布式锁、重复消费和并发一致性问题反复出现。
- 生鲜称重、多退少补等 OMS 能力进入订单模块，导致边界混乱。
- 算费逻辑分散在不同 service，简单需求也可能牵动大量 class。
从架构角度看，这不是“代码不够整洁”的问题，而是领域模型和事实来源没有稳定下来。
订单域的重构方向
订单系统的重构方向应该围绕几个问题展开：
- 订单聚合根到底维护哪些事实？
- 哪些变化属于订单状态变化，哪些属于履约、仓储、配送、售后或账务事实？
- 算费是订单内部规则，还是营销、支付、账务共同参与的决策？
- 支付方式应该是字符串判断，还是有明确语义的方法集合？
- 事件是系统事实，还是过程代码之间的通知？
千米材料里提到的 PayType 抽象、MarketingCalculator、Event Driven 和 Event Sourcing，都是围绕这些问题的尝试。
途牛支付与运营系统经验
简历里的途牛阶段覆盖了清结算、资产池、钱包、P2P、理财、信贷、支付运营、BI 和跨境支付。这里沉淀的是金融工程底座能力：
- 支付链路要能承受大促流量，例如 10K+ QPS 的压力。
- 运营需要 100+ 支付渠道的实时监控和切换能力。
- 跨境支付要同时处理线上收款、清算、费率和对账。
- BI 和 OLAP 不是旁路报表，而是运营决策和生产保障的一部分。
这类系统的稳定性不是单点代码优化能解决的，而是依赖监控、容量、降级、通道治理、对账和回滚策略共同支撑。
高一致性系统的设计原则
支付账务系统里，几个原则比具体框架更重要：
- 资金事实必须有单一真实来源，缓存和搜索只能是派生数据。
- 所有外部回调都要幂等，重复通知不能改变最终事实。
- 分布式锁不能替代交易边界和对账机制。
- 状态机要表达业务事实，而不是隐藏在过程代码里。
- 对账、差错处理和补偿流程是一等能力，不是售后脚本。
- 监控要覆盖业务指标：成功率、延迟、通道错误、清算差异和异常订单。
这也连接到 ddia-skill 的系统设计判断：交易链路不能把 Redis、ES 或消息队列当成财务事实来源。
与 AI Agent 平台的连接
支付账务经验和 AI Agent 平台看似不同，底层关注点却相似：
- 都需要明确状态和事实来源。
- 都需要幂等、回放和审计。
- 都需要可观测性和异常定位。
- 都需要把复杂流程拆成边界清楚的步骤。
- 都不能只依赖“当时看起来成功”的一次调用结果。
这就是为什么 AI Agent 项目群 里的 Runtime、Evals、Observability 和 Safety，会自然连接到支付账务系统的工程经验。