第一章 识别模块边界：限界上下文、业务能力映射与内聚性评估
模块依赖方向控制的第一项基本功，是准确识别模块边界。边界划错了，后面的接口定义、依赖倒置、信任链路设计都会跟着走偏。本章围绕领域驱动设计中的三项核心手段展开：业务能力映射 (Business Capability Mapping)、限界上下文 (Bounded Context)、内聚性评估 (Cohesion Assessment)，为后续章节打下边界识别的方法论基础。
1.1 核心概念：模块边界的两个维度
模块边界同时承载 业务归属 与 技术内聚 两个属性：
- 水平边界（层级边界）：如展现层、应用层、领域层、基础设施层，解决的是职责分离与单向依赖。
- 垂直边界（领域边界）：如订单上下文、库存上下文、支付上下文，解决的是业务能力解耦与数据所有权。
本课程重点讨论垂直边界的识别与依赖方向控制，水平分层将在后续章节处理。
1.2 三种主流边界识别方法
| 方法 | 输入 | 产出 | 适用阶段 |
|---|---|---|---|
| 业务能力映射 | 组织架构、战略规划、业务流程 | 能力矩阵、模块候选列表 | 战略设计、项目启动 |
| 限界上下文 | 领域专家访谈、事件风暴、统一语言 | 上下文地图、上下文关系图 | 战术设计、重构治理 |
| 内聚性评估 | 现有代码模块、数据依赖、变更历史 | 模块内聚评分、拆分/合并建议 | 遗留系统重构、持续演进 |
1.3 业务能力映射：从组织战略到模块候选
业务能力映射不关心已有代码结构，只从 业务本身 出发，列出企业必须具备的端到端能力。每个能力对应一个潜在的模块候选。
推荐步骤：
- 列出企业核心业务能力（如“商品管理”“订单履约”“支付结算”）。
- 按能力归属划分一级能力域（如“交易域”“供应链域”“用户域”）。
- 每个能力域对应一个高内聚模块候选。
例如，电商系统的交易域包含：购物车能力、下单能力、订单状态管理能力、退款能力。这些能力因共享相同的实体（订单、订单项）与业务规则，天然适合划入同一个模块边界。
1.4 限界上下文：领域驱动设计的边界武器
限界上下文是 DDD 中用于定义模型边界的核心构造。每个限界上下文有独立的 统一语言 和 模型，上下文之间通过上下文映射 (Context Map) 建立依赖关系。
- 核心域：最核心的业务能力，采用自定义开发、自治架构。
- 支撑子域：支撑核心域但非核心竞争力，可考虑采购或简化实现。
- 通用子域：行业通用能力（如邮件、通知），直接使用成熟方案。
反模式：将两个不同限界上下文的实体混入同一个表或同一个模块，导致模型概念膨胀、依赖方向混乱。典型的例子是将“商品主数据”与“商品库存”放在同一个模块中，违背了库存上下文的独立演进需求。
1.5 内聚性评估：量化判断模块边界是否合理
内聚性评估从 功能内聚、数据内聚、变更内聚 三个角度打分。以下是一份简化的评估表：
| 评估维度 | 高内聚特征（1~3分制中得3分） | 低内聚特征（得1分） |
|---|---|---|
| 功能内聚 | 模块内所有元素共同完成单一业务目标 | 一个模块处理两种不相关的业务场景 |
| 数据内聚 | 模块操作的数据表都属于同一领域 | 模块跨域访问多个聚合根的表 |
| 变更内聚 | 同一次变更只改本模块内的文件 | 一次需求变更横跨3个以上模块 |
当某个模块的内聚总分低于阈值时，应当考虑拆分或重组边界。
1.6 边界识别流程总览
1.7 落地检查清单
- ✅ 是否已列出所有候选模块对应的业务能力？
- ✅ 每个模块是否拥有独立的限界上下文与统一语言？
- ✅ 是否完成了内聚性打分（功能/数据/变更）？
- ✅ 低内聚模块是否已标记为“待拆分”或“待重组”？
实践建议：在项目初期，优先用业务能力映射划定 5~8 个一级模块，再通过事件风暴细化内部边界。不要追求一次到位，边界识别允许在后续迭代中调整，但必须保留明确的调整记录。