模块边界识别策略：业务域拆解、上下文映射、限界上下文划分
模块边界识别是 API 契约设计的起点，决定了服务拆分粒度与集成复杂度。本章从业务域拆解、上下文映射和限界上下文划分三个递进层次，建立一套可复用的边界判定方法。
1.1 业务域拆解
将业务能力按领域驱动设计（DDD）分层，识别出核心域、支撑域和通用域。拆解结果直接影响后续上下文划分的粒度。
| 领域类型 | 特征 | 示例（电商系统） |
|---|---|---|
| 核心域 | 竞争优势来源，投入最多资源 | 商品推荐、订单履约 |
| 支撑域 | 必须但非核心，可外购或标准化 | 支付、物流对接 |
| 通用域 | 行业通用方案，优先复用 | 用户认证、通知推送 |
实践提示：业务域拆解应与产品路线图对齐，避免过度拆分导致“微服务碎纸机”现象。建议每季度审视一次域边界有效性。
1.2 上下文映射
上下文映射（Context Map）描述不同限界上下文之间的协作关系。常用模式如下：
- 合作关系（Partnership）：两个上下文紧密配合完成同一流程，需高频双向 API 交互。
- 共享内核（Shared Kernel）：共享一组核心模型或代码库，要求严格变更同步契约。
- 客户-供应商（Customer-Supplier）：上游提供 API，下游消费；上游需满足下游契约。
- 防腐层（Anti-Corruption Layer）：下游通过适配层隔离上游模型变化，保护自身领域。
- 开放主机服务（Open Host Service）：通过统一 API 暴露上下文能力，隐藏内部实现。
- 发布语言（Published Language）：使用标准模型（如事件、DTO）作为跨上下文通信格式。
上下文映射输出应记录为 YAML 或 JSON 格式，作为架构决策记录（ADR）附件：
# context-map.yaml
upstream: order-service
downstream: payment-service
pattern: customer-supplier
contract: payment-gateway-v1
events:
- order.paid
- payment.refunded1.3 限界上下文划分
限界上下文是模块边界的最终单位。以下判定矩阵帮助在业务域与代码模块间建立映射：
| 判定维度 | 高内聚（同上下文） | 低内聚（拆分独立上下文） |
|---|---|---|
| 业务变更频率 | 在同一迭代周期内变更 | 变更节奏差异超过 2:1 |
| 聚合根访问模式 | 事务范围包含多个聚合 | 事务边界清晰，聚合独立 |
| 领域术语一致性 | 概念定义完全一致 | 术语冲突需通过防腐层映射 |
| 数据所有权 | 共享数据库或 schema | 各自拥有数据库，通过 API 交互 |
常见误区：不要将“微服务”直接等同于“限界上下文”。一个微服务可包含多个内聚的限界上下文，但反例会引入无谓的网络开销与分布式复杂性。
1.4 边界识别流程：从业务域到模块契约
下图展示了从业务域拆解到限界上下文划分的通用步骤，以及每个阶段的输出物对 API 契约设计的影响。