07｜限界上下文与协作边界
状态：第一轮工作稿；涵盖候选边界、责任、协作与反证，不代表设计完成或实现已通过。
上游：AGENTS.md → 域 → 子域。
日期：2026-09-18；编写责任：主会话；业务决策与长期维护人待指定。
1. 本层要解决的问题
在“需要什么、是什么、谁参与、怎么使用”之后，确定同一套模型和规则在哪里适用、谁拥有事实、其他参与方如何使用，以及边界失败时谁负责恢复。
BC 是模型与责任边界，不是产品端、页面、API audience、数据库 Schema 或部署服务。一个 BC 内可有多个聚合及事务；多个 BC 可共同部署。事实唯一不要求所有使用方接收一个巨大 DTO，要求每种公共语义和契约有唯一维护者。
2. 前置状态与本次结论强度
核对发现 05 的域文档仍为 working-draft，06 的十个子域仍为 placeholder。本次得到继续梳理上下文的授权，但不能据此把上游标记为已评审完成。因此本层是利用现有架构和使用场景形成的候选方案，并反向记录需要补齐的子域问题。
当前建议十个业务/支撑上下文，技术平台单独说明。数量与旧模块接近不是推导依据；每张卡片都说明继续保留、内部区分、未来拆分的理由和反例。特别是 Demand、Commerce、内容与增长推荐的边界仍需验证，不以此冻结最终数量。
横向技术能力已有通用监控与自动处置平台主讲，独立定义技术对象、转译与响应，不增列为第十一个零售业务上下文；鼎味场景包只作接入绑定。
3. 阅读顺序
- 本页：设计标准和候选全貌。
- OWNERSHIP：唯一事实归属、同名概念及技术底座边界。
- 各 BC 卡片：能力、使用者、规则、协作和边界取舍。
- CONTEXT-MAP：调用关系、信息方向、授权及流程恢复责任。
- BOUNDARY-DECISIONS：拆合备选、代价和重开条件。
- REVIEW：场景覆盖、反证、来源差异、待决项及下一步。
- 2026-09-29 交易严谨性审查：周计划与订单边界、终态不可逆、资金分配及唯一执行权；本层已同步事实归属、核心 BC 和协作责任。
4. 候选上下文
| 上下文 | 主要子域输入 | 存在理由 | 状态 |
|---|---|---|---|
| BC-01 组织、身份与授权 | SD-10 | 让所有参与者以可验证身份和明确职责访问同一系统。 | working-draft |
| BC-02 客户与业务关系 | SD-02 | 持续识别服务对象，维护客户资料、同意、服务关系与团长参与。 | working-draft |
| BC-03 商品与内容发布 | SD-01 | 清晰表达卖什么、按什么规格展示与履约，以及哪个版本已经发布。 | working-draft |
| BC-04 供给、质量与追溯 | SD-05 | 让实际物料来源、可用性、变化与流向都有可核对依据。 | working-draft |
| BC-05 预约承诺与订阅 | SD-03 | 决定什么需求能够被接受，以及如何维护预约和周期性服务承诺。 | working-draft |
| BC-06 交易、资金与售后 | SD-04 | 让购买意图成为唯一可审计商业订单，并维护与其关联的支付、取消和售后结果。 | working-draft |
| BC-07 履约与交付 | SD-06 | 把可履约的商业承诺转化为受控任务、真实包裹和可证明交付。 | working-draft |
| BC-08 财务核算 | SD-07 | 把可追溯经济来源按明确规则转成可核对账务，不混同收款与收入。 | working-draft |
| BC-09 外部渠道协作 | SD-08 | 让异构外部平台参与鼎味业务，同时隔离外部术语、状态与不确定性。 | working-draft |
| BC-10 经营分析与数据质量 | SD-09 | 让经营者知道发生了什么、统计口径是什么、结果是否可信。 | working-draft |
SD 与 BC 不是一对一约束：订阅也使用 Commerce，商品可售需要 Catalog/Supply/Demand/Commerce，召回跨 Supply/Fulfillment/Commerce，经营分析消费全部事实 Owner。上表只列主输入，不表示其他子域不参与。
5. 边界判断标准
- 同一术语是否具有同一业务含义，是否需要独立生命周期？
- 谁有权改变事实，哪些规则需要在一次本地决定中同时成立？
- 使用者、业务政策、变更节奏和责任是否有独立性？
- 拆开是否引入不可接受的一致性窗口；合并是否掩盖不同事实或成为万能模块？
- 输入不可信、依赖失效、并发、重放、迁移和恢复时边界能否继续成立？
- 哪个具体反例会推翻当前建议，何时应重新评估？
公开的类型、ID 与消息是发布契约，不因大家都引用就自动成为 DDD Shared Kernel。共享内核只容纳确实需要联合维护且范围很小的基础类型；不得共享可变业务实体或所有领域 Repository。
6. 生效与过渡
下一层：08｜领域模型与业务规则 已开始对象、一致性和生命周期分析；其发现反馈到本层，不表示当前候选上下文已定案。
本目录是限界上下文重整的唯一编辑主线。旧 BC 目录、Context Map 和 30 模块设计保留作为来源；对应过渡原则见 05 §3。新建议不自动覆盖生效约束，也不把有冲突的旧稿继续当新基线。
本轮没有改公共事件名称、Process Registry、API 路径、REQ、数据库或运行状态。后续边界变化必须核对所有消费者、消息和数据迁移，保留兼容及恢复方案后才实施。