DM-06｜交易、资金与售后领域模型
状态：working-draft；候选模型，不是已锁定的结构或状态契约。
上游：BC-06；输入：旧聚合材料（历史材料保留在docs_bak/）。
编写：主会话；业务决策与长期维护人：待指定。日期：2026-09-18。
1. 对象分类与候选聚合
| 对象 | 分类 | 维护什么 | 要保护的业务含义 |
|---|---|---|---|
| Cart / PriceBook | 候选根 | 选购意图；价格规则版本 | 购物车不占容量，历史价格规则不覆盖 |
| PriceQuote | 候选根及冻结结果 | 本次价格、数量、分摊及来源版本 | 过期策略需确定；不能隐式改已接受金额 |
| CouponGrant / BenefitReservation | 候选根 | 权益归属及使用预约 | 重复与并发消费受控 |
| Order | 候选根 | 订单行、商业状态、来源与成交快照 | 不拥有支付/履约全部生命周期 |
| PurchaseBatch | 候选根 | 明确购买范围、关联订单及结算范围版本 | 不等于自然周；结算与新增替换有准入守卫 |
| ReplacementRequest | 协调流程对象 | 前驱/后继、停止证据、分配和补偿进度 | 旧单终态不可逆；新旧不能双重执行 |
| FundingAllocation / AllocationGuard | 追加分配记录 / 原款额度守卫 | 每笔原实收在可用、占用、消费、退款预留和已退间的合法变化 | 原款不可双花；UNKNOWN 不释放，资金与数量分别守恒 |
| PaymentIntent / PaymentAttempt | 候选根 / 子实体或独立记录待决 | 收款目标；单次外部尝试 | 每次尝试与业务收款目标可区分 |
| PaymentTransaction | 不可变经验证资金事实 | 真实收款结果和外部依据 | 客户端回跳不证明到账 |
| Refund / RefundBudget | 候选根 / 候选资金额度守卫 | 退款目标与分摊；原收款可退额度 | 待定外部结果也需保留额度，防并发超退 |
| AfterSaleCase / Resolution | 候选根 / 版本化裁决 | 诉求、证据、方案与执行依据 | 批准不等于下游完成 |
| Confirmation / Cancellation | 协调流程对象 | 商业接受、取消的跨责任区动作及回执 | 不替代每日ConfirmationRecord；换菜统一由ReplacementRequest协调，不另设Substitution事实源 |
| SettlementRun / SettlementRecord | 结算执行 / 已验证结果 | 固定范围和依据版本，核算结果及必要退款回执 | 重复调度不新增退款目标；范围未稳定不结清 |
| ReconciliationRun / Adjustment | 对账执行 / 关联更正 | 匹配差异；结清后新经济事实的独立处置 | 不直接改真实支付或重开旧批次；精确更正生命周期仍需设计 |
“候选根”表示需要独立身份、生命周期及一致性责任的提案，不代表每行已经确定为一个事务。历史、子实体、值对象及集合的最终边界还需基于规模和不变量核对。
2. 关系与引用
Order 引用 Quote 并冻结本次接受条件；PaymentIntent 引用业务收款目标；Refund 引用合法原交易与售后/取消依据；AfterSaleCase 关联 OrderLine/Package 等目标。履约组数量、拆单和替代规则需先确定，不默认一单一组。
值对象及共享引用的统一含义见 MODELING-RULES。上下文之间引用 ID、版本或不可变快照，不共享可变实体。
3. 生命周期
Order 区分商业建立/接受与不可逆终态，付款和每日配送确认不塞入同一 status；资金操作、替换与批次各有独立候选机器，唯一迁移见状态定义。Case 的受理、评估、方案、执行、验证关闭尚需单独精确设计，不能视为六机定义已经覆盖全部售后。
本页概述对象责任；六机范围内的精确候选迁移以 state 单源定义为准，其余对象仍为语义级路径。两者均未锁定，不能直接生成生产枚举。业务对象状态、协调进度和技术回执分别保存与展示。
4. 业务动作与事件
顾客创建、查询和按规则申请取消；客服执行明确变更命令；支付适配提交观察；售后人员裁决但资金成功须验证。事件候选：“订单已创建”“付款依据已验证”“订单商业接受已成立”“退款已验证成功”“售后方案已批准”。
本节事件名称为中文业务语义候选；state 中的事件标识只用于候选状态模型，不是已发布的公共事件 Registry。后续契约设计仍须确定输入、前置条件、结果、错误和受众。
5. 强一致性及并发边界
订单与来源唯一性一起提交；退款创建与原交易可退额度预留一起成立，单个 Refund 的乐观锁不能防多个退款超额；资金 UNKNOWN 不释放预留再盲重试。订单确认协调 Demand 及权益，并保留已发生资金事实，不宣称跨 BC 原子回滚。
新增原款分配/替换/退款共同的额度守卫，及前驱唯一替换、订单行数量份额与结算范围准入守卫。资金核对式、停止后关联新单、自动结算与终态更正见TRANSACTION-INTEGRITY。金额计算使用整数最小货币单位，优惠、重量差额及退款分摊未冻结前不可自行上线默认算法。
共同约束见 CONSISTENCY：单根版本不能替代跨对象约束；如需同 BC 多根本地事务，必须明确保护范围与理由，不能默认为整个 BC 一把锁。
6. 反例、未知与下一步
双击下单、不同幂等键同源意图、两个售后同时退款、退款未知再申请、已发货取消、零额/外部付款依据、替代后快照追溯。订单不跨配送日期和地址；未切配可申请取消/换菜，开工后走实际处置；按实际重量计价。部分商品修改、超重、费用和退款细则待定，见确认政策。
上述反例是设计验证目标，尚未执行产品测试。先关闭影响边界的不确定性，再完善动作级迁移表及精确模型。身份、权限与业务状态的联动仍遵守 07 的统一授权接缝，不在本页复制一套权限规则。
7. 后台定价与订单变更输入（2026-09-19）
后台岗位动线提出价格草稿、复核、生效、更正，以及订单改址/改期的变更请求。它们是模型补充需求，尚不自动定为独立聚合或生产枚举。
价格提案必须表达适用 SKU/计量、币种、范围、生效区间、来源版本与批准依据。生效版本保持可追溯；撤回未生效提案与更正已生效价格不同。旧报价有效性待政策确定，已成交金额不跟随价格主数据变化。
订单变更需要独立可追溯的请求身份、客户确认、原成交依据、目标安排、参与 Owner 决定和分步结果。已成交换菜终止旧单并关联新单；允许的非标的修正追加记录不覆盖原快照。地址簿、商业订单与履约安排是不同对象；取消、改址、改期不得合并成任意字段编辑。旧单终态后，补发、退款、售后和调整使用关联对象继续，不改变旧商业终点。
责任、失败恢复和跨端动作语义见 CONTEXT-MAP §5。未切配可申请取消/换菜与配送确认截止已明确；部分数量变更、改址改期、费用及审批细则仍待业务规则明确。