BC-06｜交易、资金与售后（commerce）
状态：working-draft；本次边界建议，未批准为完整新基线。
Design=draft；Contract=not-defined-here；Implementation=not-assessed；Verification=document-review-only。
上游：SD-04（仍为候选占位）
输入：既有模块设计（历史材料保留在docs_bak/）
编写责任：主会话；业务决策 / 长期维护责任人：待指定。日期：2026-09-18。
1. 需要什么，它是什么
让购买意图成为唯一可审计商业订单，并维护与其关联的支付、取消和售后结果。
统一语言：Quote 是成交条件依据；Order 是商业承诺记录；PaymentTransaction 是经验证的资金事实；AfterSaleCase 是售后诉求与裁决；Refund 是退款生命周期。它们不能共用一个状态。
2026-09-29：PurchaseBatch 是明确购买/结算范围，不等于自然周；FundingAllocation 记录原实收分配，ReplacementRequest 协调旧单终止及关联新单，Settlement/Adjustment 处理自动核算与后续更正。订单终态无任何恢复出边；“已付待本次确认”正常存在，付款后即可提前确认。订单不跨日期/地址；确认超时以cancelled记录取消及原因，不复活旧单。商品按实际重量计价，退款方式仍待决。规则、取舍和后台职责以交易级严谨性为主讲。
2. 拥有与不拥有
拥有： 购物车与定价报价、订单及不可变成交快照、支付意图和验证资金事实、订单确认与取消流程、售后方案、退款、交易结算和交易对账。
不拥有： 商品主数据、容量和物料账本、现场任务、会计分录、客户地址簿、外部渠道原始订单。
这里列出事实族和职责，不直接定义数据库表、聚合事务范围或最终接口名称；详细模型须在下一层继续验证。
3. 谁参与，怎样使用
顾客在小程序购买和查询本人订单；客服在后台按对象范围查询和执行受控动作；订阅和 Channel 经内部契约请求标准订单；支付 Provider 提供可验证观察。
典型场景：结算接受报价并申请 Hold → 幂等创建订单和支付意图 → 验证付款依据 → 确认容量与规则 → 确认订单。取消先判断商业资格及履约停止结果，再按政策处理退款和释放，不能一键把所有状态改为成功。
4. 如何与其他上下文协作
读 Customer/Catalog 快照，调用 Demand 占用命令；向 Fulfillment 发布确认与受控变更意图；发布资金/交易事实供 Finance 消费；售后请求 Supply/履约执行各自处置。
调用方向、信息方向、流程协调者和失败责任统一见 CONTEXT-MAP；事实边界及混淆项见 OWNERSHIP。不使用共享可变实体或跨 Owner 写表。
5. 不变量、权限与一致性
同一明确来源意图不重复生成订单效果，合法多单按受控购买范围区分；支付成功不等于商业接受，更不等于每日配送确认。不得人工标记真实资金到账；退款预留、订单占用、消费与已退互斥守恒。终态订单不可恢复，已成交换菜使用新意图关联后继单；原款仅在停止和额度证据成立后受控分配，不能覆盖原快照或依赖单 Refund 锁防超退。
所有入口遵循 统一授权接缝。本上下文负责自己的资源关系和业务动作条件，不能仅凭客户端提交的角色或对象归属放行。
6. 失败、并发与恢复
支付/退款 UNKNOWN 查原操作；取消与付款晚到由协调流程对账；跨 BC 不假定分布式原子事务；已付无法确认要可见地恢复或补偿。
部署和数据库共用不构成跨上下文原子性承诺。需要立即成立的约束在对应事实 Owner 内执行；跨域步骤记录意图、版本、结果与恢复进度。
7. 边界取舍与可能推翻结论的证据
当前建议保留 Commerce BC，并明确定价、订单、支付退款、售后四个内部模型责任区，禁止万能 Repository。拆四个 BC 会增加资金与取消等交接；独立资金业务、结算团队或外部服务边界出现时需重新评估。
反证检查：验证跨端同一订单、重复下单、超额退款、已发货取消、退款成功但 Case 未完成、晚到支付。若某内部能力不能定义独立状态与接口，即表明大上下文已掩盖责任。
上述是设计反例清单，尚未执行产品测试。拆合讨论及重开条件见 BOUNDARY-DECISIONS。
8. 未决事项与后续交付
允许修改的字段/动作、取消与退款政策、PaymentBasis、售后关闭条件及资金职责分离待明确。
先核对本页业务范围及上下文边界，再细化模型、不变量、状态、命令/查询/事件和授权契约；最后派生完整业务增量 REQ。不得据本稿直接锁定开发接口。当前未决项统一归入DECISIONS对应D项；REVIEW仅保留历史审查及Q项来源，不另作活动决策台账。