# 07｜限界上下文与协作边界

> 状态：第一轮工作稿；涵盖候选边界、责任、协作与反证，不代表设计完成或实现已通过。\
> 上游：[AGENTS.md](../../../AGENTS.md) → [域](../05-domain/DOMAIN.md) → [子域](../06-subdomain/README.md)。\
> 日期：2026-09-18；编写责任：主会话；业务决策与长期维护人待指定。

## 1. 本层要解决的问题

在“需要什么、是什么、谁参与、怎么使用”之后，确定同一套模型和规则在哪里适用、谁拥有事实、其他参与方如何使用，以及边界失败时谁负责恢复。

BC 是模型与责任边界，不是产品端、页面、API audience、数据库 Schema 或部署服务。一个 BC 内可有多个聚合及事务；多个 BC 可共同部署。事实唯一不要求所有使用方接收一个巨大 DTO，要求每种公共语义和契约有唯一维护者。

## 2. 前置状态与本次结论强度

核对发现 05 的域文档仍为 working-draft，06 的十个子域仍为 placeholder。本次得到继续梳理上下文的授权，但不能据此把上游标记为已评审完成。因此本层是利用现有架构和使用场景形成的**候选方案**，并反向记录需要补齐的子域问题。

当前建议十个业务/支撑上下文，技术平台单独说明。数量与旧模块接近不是推导依据；每张卡片都说明继续保留、内部区分、未来拆分的理由和反例。特别是 Demand、Commerce、内容与增长推荐的边界仍需验证，不以此冻结最终数量。

横向技术能力已有[通用监控与自动处置平台](../platform/MONITORING-AUTOMATION.md)主讲，独立定义技术对象、转译与响应，不增列为第十一个零售业务上下文；[鼎味场景包](../platform/DINGWEI-SCENARIO-PACK.md)只作接入绑定。

## 3. 阅读顺序

1. 本页：设计标准和候选全貌。
2. [OWNERSHIP](OWNERSHIP.md)：唯一事实归属、同名概念及技术底座边界。
3. 各 BC 卡片：能力、使用者、规则、协作和边界取舍。
4. [CONTEXT-MAP](CONTEXT-MAP.md)：调用关系、信息方向、授权及流程恢复责任。
5. [BOUNDARY-DECISIONS](BOUNDARY-DECISIONS.md)：拆合备选、代价和重开条件。
6. [REVIEW](REVIEW.md)：场景覆盖、反证、来源差异、待决项及下一步。
7. [2026-09-29 交易严谨性审查](../../reports/review/ARCH-2026-09-29-transaction-integrity.md)：周计划与订单边界、终态不可逆、资金分配及唯一执行权；本层已同步事实归属、核心 BC 和协作责任。

## 4. 候选上下文

| 上下文 | 主要子域输入 | 存在理由 | 状态 |
|:---|:---|:---|:---|
| [BC-01 组织、身份与授权](bc-01-identity.md) | SD-10 | 让所有参与者以可验证身份和明确职责访问同一系统。 | working-draft |
| [BC-02 客户与业务关系](bc-02-customer.md) | SD-02 | 持续识别服务对象，维护客户资料、同意、服务关系与团长参与。 | working-draft |
| [BC-03 商品与内容发布](bc-03-catalog.md) | SD-01 | 清晰表达卖什么、按什么规格展示与履约，以及哪个版本已经发布。 | working-draft |
| [BC-04 供给、质量与追溯](bc-04-supply.md) | SD-05 | 让实际物料来源、可用性、变化与流向都有可核对依据。 | working-draft |
| [BC-05 预约承诺与订阅](bc-05-demand.md) | SD-03 | 决定什么需求能够被接受，以及如何维护预约和周期性服务承诺。 | working-draft |
| [BC-06 交易、资金与售后](bc-06-commerce.md) | SD-04 | 让购买意图成为唯一可审计商业订单，并维护与其关联的支付、取消和售后结果。 | working-draft |
| [BC-07 履约与交付](bc-07-fulfillment.md) | SD-06 | 把可履约的商业承诺转化为受控任务、真实包裹和可证明交付。 | working-draft |
| [BC-08 财务核算](bc-08-finance.md) | SD-07 | 把可追溯经济来源按明确规则转成可核对账务，不混同收款与收入。 | working-draft |
| [BC-09 外部渠道协作](bc-09-channel.md) | SD-08 | 让异构外部平台参与鼎味业务，同时隔离外部术语、状态与不确定性。 | working-draft |
| [BC-10 经营分析与数据质量](bc-10-analytics.md) | SD-09 | 让经营者知道发生了什么、统计口径是什么、结果是否可信。 | working-draft |

SD 与 BC 不是一对一约束：订阅也使用 Commerce，商品可售需要 Catalog/Supply/Demand/Commerce，召回跨 Supply/Fulfillment/Commerce，经营分析消费全部事实 Owner。上表只列主输入，不表示其他子域不参与。

## 5. 边界判断标准

- 同一术语是否具有同一业务含义，是否需要独立生命周期？
- 谁有权改变事实，哪些规则需要在一次本地决定中同时成立？
- 使用者、业务政策、变更节奏和责任是否有独立性？
- 拆开是否引入不可接受的一致性窗口；合并是否掩盖不同事实或成为万能模块？
- 输入不可信、依赖失效、并发、重放、迁移和恢复时边界能否继续成立？
- 哪个具体反例会推翻当前建议，何时应重新评估？

公开的类型、ID 与消息是发布契约，不因大家都引用就自动成为 DDD Shared Kernel。共享内核只容纳确实需要联合维护且范围很小的基础类型；不得共享可变业务实体或所有领域 Repository。

## 6. 生效与过渡

下一层：[08｜领域模型与业务规则](../08-domain-model/README.md) 已开始对象、一致性和生命周期分析；其发现反馈到本层，不表示当前候选上下文已定案。

本目录是限界上下文重整的唯一编辑主线。旧 BC 目录、Context Map 和 30 模块设计保留作为来源；对应过渡原则见 [05 §3](../05-domain/README.md#3-与旧材料的过渡关系)。新建议不自动覆盖生效约束，也不把有冲突的旧稿继续当新基线。

本轮没有改公共事件名称、Process Registry、API 路径、REQ、数据库或运行状态。后续边界变化必须核对所有消费者、消息和数据迁移，保留兼容及恢复方案后才实施。