一致性边界与订单动作检验
状态：working-draft；以下是模型决策与验证要求，不是已经实现的数据库方案。日期：2026-09-18。
1. 必须单独解决的跨对象强约束
| 场景 | 为什么单根版本不够 | 候选处理方向 | 必须寻找的反例 |
|---|---|---|---|
| 多个 Refund 使用同一收款 | 每个退款都可能独立看到足够可退余额 | 原收款目标的额度守卫原子预留/核销，关联退款及未知结果 | 两个不同 Case 同时申请最后可退额 |
| 一个 Hold 占多个 CapacityBucket | 单 Bucket 成功可能遗留部分资源 | Demand 内对资源集合受控全有或全无提交；若改变为预留协议，必须明确中间状态和恢复 | 部分资源不足、锁冲突、持有过程宕机 |
| 预约改期 | 新旧承诺分开提交会双占或丢原安排 | 未改变原义务的拒绝保留原安排；已冻结则走明确停止/处置，不静默恢复。跨域按停止握手和新授权推进 | 新承诺成功但响应丢失，旧单已终态却被恢复 |
| 每日确认与到期 | 两进程可读到同一个待确认状态 | Demand 同安排 revision 和互斥时间谓词条件提交 | 到期后晚到确认/费用使旧安排复活 |
| 冻结与开工 | 只锁订单不能锁住已经派出的任务 | Fulfillment 同一执行 gate + generation/fence + 数量谱系守卫 | 两张不同订单或旧设备同时执行同一份数量 |
| 替换与退款 | 各自单根版本正确仍可双花同笔钱 | Commerce 原收款切片、分配、退款预留及来源守卫原子提交 | 旧款已退款 UNKNOWN 仍给新单抵扣 |
| 批次结算与新增替换 | 结算快照之外可能出现新义务 | 同批次范围版本与变更准入互斥；闭合后新经济事实用 Adjustment | 退款后后继仍按旧可用余额放行 |
| 多 Lot 加工转换 | 只锁 TransformationRun 不保护输入额度 | Supply 内校验输入、质量及变化，统一提交账本与输出事实；明确锁顺序及竞争资源 | 扣第一个 Lot 后失败、隔离在校验后发生 |
| JournalEntry 与 AccountingPeriod | 分录平衡不保证过账时期间仍开放 | 提交时与期间门禁协调并保护经济来源唯一性 | 关账和过账同时执行、规则改版重放 |
| 默认地址/发布目标唯一 | 单地址或单 Publication 版本不保护跨对象唯一 | 独立选择/生效指针或明确唯一约束与版本守卫 | 两个对象同时成为默认或同时覆盖同一目标 |
| Task 完成与依赖门禁 | Task 状态正确不证明当前依赖仍有效 | 提交时验证适用依赖版本与质量门禁；跨域门禁定义时效和撤销策略 | 旧离线动作在改派、隔离后补传 |
以上候选策略可能需要合并聚合、采用同 BC 多根本地事务或设计保留中间状态的协议。应根据争用、原子范围、失败恢复和业务允许的等待条件比较后定案；不能仅凭架构偏好强制“一条命令只写一个根”。
2. 跨上下文的承诺
结算、确认、取消、退款、履约、召回都沿用 07 协调责任。跨域协议保存意图、各步骤身份、必要版本、回执和恢复进度，不假设一个数据库使所有步骤可原子回滚。
- 外部资金动作与物理交付不可随意回滚；超时先查原操作，再决定补偿。
- 内部事实提交与其 Outbox 在本地保持一致；事件投递至少一次时，消费者需技术去重与业务唯一性双重保护。
- 原始用户撤权后，新业务动作停止；已经承担的退款、清理等义务通过独立受限恢复身份继续核验，不能遗弃。
- 数据投影用于展示，写操作回 Owner 判断；传播时限、质量状态失效时能否继续必须有具体契约。
3. 订单动作语义工作表
本表把“后台修改订单”拆成业务意图。未切配可申请取消/换菜、确认超时自动取消已经明确；地址改期、费用和部分商品处置细则仍待明确。精确确认窗口见确认政策。
| 动作 | 发起者 | 判断与修改责任 | 结果 | 必须拒绝/恢复的情况 |
|---|---|---|---|---|
| 创建订单 | 顾客 / 周期流程 / 渠道 | Commerce 接受明确来源；分别使用适用流程协调 Demand 与资金依据 | 每个被接受拆分范围的唯一订单及当前商业接受进度；一次购买可多单 | 来源重复、报价变化、占用失败；不因重试新增订单；商业接受不代替每日确认 |
| 查询订单 | 顾客 / 授权员工 | Commerce 对象范围校验，组合必要履约摘要 | 同一 OrderId，不同授权视图 | 无权、源不可用、投影过期，不能假装未发生 |
| 请求修正联系方式 | 顾客 / 客服，是否允许待政策 | Commerce 受控变更依据，必要时通知 Fulfillment；Customer 地址簿独立 | 保留成交快照及后续修正记录 | 已交付、权限不足、并发修改；不能覆盖历史证据 |
| 请求改期 | 顾客 / 客服，是否允许待政策 | Commerce 协调商业变更；Demand 替换承诺；Fulfillment 检查执行影响 | 明确的新安排或恢复中的请求 | 新容量不足、已不可停止、部分步骤失败 |
| 请求取消 | 顾客 / 客服 / 授权流程 | Commerce 裁决并协调停止、释放与退款 | 请求结果、商业结果和副作用进度分别可见 | 已发生交付、资金未知、晚到支付；不能一键改全链终态 |
| 申请/裁决售后 | 顾客 / 售后人员 | AfterSaleCase 维护方案；资金与物料等 Owner 执行动作 | 可追踪 Case 和分项执行结果 | 重复诉求、超额退款、证据不足、回收未完成 |
查询的 allowed actions 是当时的判断；执行要核对更新后的角色、对象版本及业务条件，返回明确冲突或拒绝原因。
4. 迁移与模型修订
本轮完整不变量、资金核对式及跨 Owner 恢复协议见TRANSACTION-INTEGRITY，候选迁移由状态定义主讲。这里的候选方案不证明数据库锁、远端 fence 或真实支付已实现。
模型定案前不迁移业务数据。以后改变根边界、业务身份或状态机时，必须盘点旧标识、历史快照、在途流程、消息版本、唯一键及消费者；迁移前后对账，明确唯一写入方，并准备兼容读取和恢复路径。
不能把“旧状态映射不到”强行变成成功或取消。无法确定的历史结果保留待核验；真实支付、分录、交付等事实通过补偿或更正处理，不为方便迁移删除。