边界备选、取舍与重开条件
状态：proposed；不替代正式 ADR 或上游业务范围确认。日期：2026-09-18。
编写与后续分析：主会话；业务取舍与长期责任人仍待指定。
1. 拆合建议
| 编号 / 边界 | 当前建议与依据 | 备选及代价 | 推翻/重开条件 | 后续动作 |
|---|---|---|---|---|
| B-01 Identity / Customer | 分离；登录与授权、业务关系有不同生命周期 | 合并可减少调用，但账号停用、客户保留、同意处理容易互相覆盖 | 存在跨两者必须一次本地完成且无法通过初始化/补偿处理的真实不变量 | 验证注册部分失败、合并和删除路径 |
| B-02 Catalog / Content | 商品与当前经营内容保留同一候选 BC，区分规格与发布模型 | 独立 Content 有利于通用编辑；增加发布与商品引用一致性责任 | 内容不再围绕商品，形成独立编辑政策、受众或渠道生命周期 | 补首页、活动、推荐规则完整用例，避免泛 CMS 假设 |
| B-03 Demand / Subscription | 暂保留 Demand，两条内部能力线明确隔离；复用承诺与周期流程 | 拆 Subscription 可隔离长期合同和权益；需明确与容量、订单的协议和补偿 | 权益转让、独立计费、多服务履约等规则形成独立语言及所有权 | Q-02；在冻结聚合/API 前明确，不拖到实现再决定 |
| B-04 Commerce 内部 | 保留交易上下文，四个内部模型责任区；统一交易链但分离状态 | 拆 Pricing、Order、Payment、After-sales 可独立演进；会扩大取消/退款/报价协议面 | 支付成为跨多业务产品的独立资金能力，或售后有独立规则团队和变化节奏 | Q-02；验证不同责任区的输入输出及余额约束，不共享万能 Repository |
| B-05 Supply / Fulfillment | 分离；物料与质量事实、人员任务与包裹事实不同 | 合并降低调用数量但把作业完成误当质量及账本完成 | 证明跨界原子约束无法由 Supply 本地命令及履约门禁保护 | 先用隔离与分配、包装绑定失败等反例验证 |
| B-06 Supply / Quality | 保留同一责任簇，物料分配本地校验质量 | 独立 Quality 可覆盖更广质量治理；需防撤销传播延迟导致错误使用 | 独立质量业务范围超出供给，策略和责任确有独立性 | Q-07；工作站质量接缝需单列模型，不把所有质量词强塞进批次 |
| B-07 Fulfillment / Delivery | 当前保持统一交付链，内部模型独立 | 独立 Delivery 有利于承运网络；新增交接责任与失败回执协议 | 独立承运结算、跨商户运输或多委托方业务成立 | 核对配送范围后再判断，不由 App 页面决定 |
| B-08 Commerce / Finance | 分离；经济源事实与核算解释有不同规则与时点 | 合并容易把到账等于收入；以 Analytics 替代会丢失账务写入责任 | 若拟简化核算范围，必须由业务明确撤销相关能力，而非实现省略 | 验证资金成功但过账阻塞与来源更正 |
| B-09 Channel / 各业务 Owner | 单独防腐边界，Provider 作为适配器 | 各 BC 各自理解外部商家协议会重复同步/映射；每 Provider 一套业务模型会分裂订单 | Provider 引入新的商业责任，不只是接口差异 | 新渠道上线先评估业务语义，再制定 Adapter Contract |
| B-10 Analytics / 推荐决策 | Analytics 保持只读分析；已有推荐内容归 Catalog、偏好归 Customer | 把规则、实验分配和决策全塞 Analytics 会产生未声明写模型；独立 Decision BC 则新增边界 | 实验与推荐形成可审计决策生命周期（现有 REQ 已有信号） | Q-03；优先补业务场景后决定，不把未知伪装已覆盖 |
| B-11 Customer / Growth | 团长资格活动关系暂归 Customer；归因算法和权益待判 | 独立 Growth 可形成规则闭环；过早拆分可能只有页面分组，没有独立模型 | 获客归因、奖励、佣金或资格变更形成独立不变量 | Q-04；盘点 REQ-043–046 和已明确来源语义 |
| B-12 Platform / 业务流程 | 通用监控与自动处置拥有技术生命周期；业务流程语义和裁决仍归业务Owner | 仅做告警面板不覆盖平台；万能业务工作流又会虚化事实Owner | 场景包必须修改内核领域分支、重复引擎路由或不能解释副作用时重审 | 主讲见平台设计，精确合同及引擎验证见D-15；不推导独立部署拓扑 |
“暂保留”不是用现状代替设计；它使当前已知场景有一个可评审的责任建议，同时以明确反例检验是否必须拆分。待决边界不能作为正式 Contract 的默认决定。
2. 边界变化如何安全落地
2026-09-29：一周无忧与不可逆订单的增量取舍
| 编号 | 建议 | 不选的方案及代价 | 推翻条件 / 恢复路线 |
|---|---|---|---|
| B-13 | Customer 餐次意图、Commerce 购买批次/独立订单、Demand 每日授权分开 | 整周万能订单会使一天取消扩散；订阅合同默认出单/配送不符主动确认 | 分组政策证明独立义务粒度不同则调整订单范围，不合并全部事实 |
| B-14 | 已成交换菜先永久停止旧执行、旧单终态，再关联新单 | 原单原地替换标的损失承诺历史；先放新单再停止旧单可能双履约 | 明确业务需不同换单协议时重审 guard/补偿；不得牺牲终态不可逆 |
| B-15 | 原收款额度和分配在 Commerce 内受保护提交，退款/重分配共享守卫 | 每个退款/订单独立乐观锁无法防共同额度超用；通用钱包扩张业务责任 | 未来独立资金产品成立再拆 Owner，迁移需逐笔守恒核验 |
| B-16 | Fulfillment 执行 gate 是冻结/开工裁决点，配合代际 fence 与停止墓碑 | 仅订单状态或队列撤回不能挡旧设备/旧事件 | 现场无法执行 fence 时禁止相应离线开工，先补设备协议再承诺安全 |
| B-17 | 批次核对汇总，终态后新经济事实另建调整；不规定每单退款等待整批结束 | 人工常规核算不能支撑无忧体验；直接重开已结清批次容易重复退费 | 退款去向/时点见DECISIONS D-05；未知款核验不伪造结清 |
以上技术边界仍为proposed；不因此将已确认的拆单、取消和确认窗口降回待选，业务依据见确认政策。完整协议、残余风险和实际责任人缺口见交易级严谨性。B-03 的订阅候选边界不再用作周计划默认模型。
本轮只形成设计工作稿，无代码或数据库迁移。将来拆合上下文时，至少需要：
- 列出事实和历史标识迁移清单，确定切换时刻的唯一写入者。
- 列出 API、事件、进程、投影和外部消费者；评估兼容窗口及版本策略。
- 通过适配保持旧契约的明确定义，禁止两个 Owner 同时写同一事实。
- 回填与校验历史关系、余额、幂等键及审计；冻结、转移或恢复在途流程。
- 区分可回滚的软件/路由与不可撤销的资金/物理事实；后者采用补偿或前向修复。
- 验证跨端场景后切换；保留回源、对账与恢复责任。
具体数据策略待边界决策后形成。不能用“以后微服务拆分”替代现在的事实归属和一致性设计。