模块边界识别与划分方法：业务域边界、限界上下文、防腐层边界

模块边界是Repository解耦的起始锚点。错误的边界划分会导致腐败扩散、职责重叠或无效的防腐层。本章从三个协作层次定义边界：业务域边界、限界上下文（Bounded Context）、防腐层（Anti-Corruption Layer，ACL）边界，并给出可落地的识别方法与验收指标。

2.1 业务域边界

• 定义：基于组织业务能力或子域（Subdomain）的宏观切分，每个子域对应一个独立的业务问题空间。
• 识别方法：事件风暴（Event Storming）、领域专家访谈、端到端业务流程图。
• 数据流：域间以异步事件或领域消息为主，不允许多域共享数据库事务。
• 控制流：域间调用应限于查询或通知，避免长流程同步命令。
• 信任链路：同一业务域内的模块信任度高，跨域必须通过显式契约或事件总线。

2.2 限界上下文

• 定义：DDD 核心模式，每个上下文拥有独立的通用语言（Ubiquitous Language）、模型和实现。
• 划分原则：
  • 团队边界：一个限界上下文原则上由一个团队维护。
  • 数据库边界：每个上下文拥有私有数据库。
  • 部署边界：每个上下文可独立部署与发布。
• 组件职责：聚合根封装业务不变量，Repository 负责聚合的持久化与重建。
• 控制流：上下文间通过应用服务（Application Service）或领域事件通信，禁止直接访问其他上下文的 Repository 或数据库。
• 信任链路：上下文边界是信任边界，跨上下文消息必须经过显式映射或防腐层，不可泄露内部模型。

2.3 防腐层边界

• 定义：保护核心域免受外部系统（遗留、第三方、上游限界上下文）模型污染的隔离设施。
• 放置位置：系统边界（与外系统交互处）或两个限界上下文之间（当上游上下文无法按需改变时）。
• 组件职责：
  • 翻译：将外部模型转换为内部核心模型。
  • 适配：封装协议/格式差异（REST ↔ RPC，XML ↔ JSON）。
  • 版本隔离：对外部接口变化进行降级或熔断。
• 数据流：上游请求 → ACL 适配器 → 内部服务；内部数据 → ACL 翻译器 → 外部期望格式。
• 信任链路：防腐层是单向信任中介——对外部不信任，对内部提供干净接口。

2.4 三者关系与综合策略

业务域边界提供宏观地图，限界上下文细化内部模型边界，防腐层在必要位置隔离不确定性。下图展示三种边界的嵌套关系及信任链路方向：

2.5 选型权衡

2.6 风险点与避坑

• 边界漂移：随着迭代，业务域边界可能移动，导致上下文映射混乱。对策：每迭代周期进行一次边界域对齐评审。
• 共享模型污染：两个限界上下文共用同一枚举或 VO 类，造成循环依赖。对策：复制模型，通过事件同步。
• 过度防腐：对可信的内部上下文也加 ACL，徒增复杂度和延迟。对策：仅对外部不可控系统或频繁变更的上游上下文使用。
• 隐式依赖：通过数据库视图、缓存或配置共享绕过边界。对策：将基础设施隔离在上下文内，配置独立。

2.7 落地步骤

1. 事件风暴：组织领域专家与工程团队一起识别业务事件、命令、外部依赖，产出业务域图。
2. 划分限界上下文：根据事件归属和通用语言一致性，将业务域切分为上下文，并记录上下文映射矩阵（Context Map）。
3. 识别非可信边界：对遗留系统、第三方 SaaS、频繁变更的上游上下文，设计防腐层接口。
4. 定义契约：使用 JSON Schema 或 Protobuf 明确定义上下文间的消息结构和错误码。
5. 独立开发与测试：每个上下文可独立构建、部署，防腐层需提供单元测试验证转换逻辑。
6. 持续验证：在 CI 中增加边界一致性检查（如契约测试、性能基线）。

2.8 验收标准

• 每个模块（上下文）拥有明确的外部 API 文档和私有数据库。
• 跨上下文通信仅通过定义好的消息或事件发生，无直接 Repository 访问或 SQL 关联。
• 每个防腐层可独立部署，并通过稳定性测试（如接口响应500ms、错误率<0.1%）。
• 至少完成一次“跨上下文模拟升级”演练，确认只在防腐层处修改不影响核心域。
• 业务域边界在架构文档中标注，且与组织团队划分一致。