业务域到系统域的映射：业务能力拆解、子域划分与限界上下文

业务需求与系统实现之间存在天然鸿沟。业务人员谈论的是“订单生命周期”“库存周转”“支付对账”，而技术团队需要定义服务边界、数据库拆分、接口协议。第 2 章聚焦于如何将业务域的结构化知识，精准映射为系统域的限界上下文与子域边界，为后续分层、模块、数据流设计打下稳定基础。

核心观点：一个限界上下文 = 一个业务子域 = 一组内聚的业务能力。三者对齐越紧密，系统演化成本越低。

2.1 业务能力拆解：从组织架构到业务活动

业务能力是企业能够做什么（what），而非怎么做（how）。拆解时通常采用三级粒度：L1 能力域（如“销售”）、L2 能力组（如“订单管理”）、L3 业务活动（如“创建订单”“修改订单”“取消订单”）。

层次 举例 映射目标
L1 能力域 销售、履约、财务 识别宏观业务域
L2 能力组 订单管理、库存分配、支付处理 候选子域 / 限界上下文
L3 业务活动 提交订单、扣减库存、发起支付 领域事件 / 命令 / 聚合根

拆解产出物通常是一张业务能力热力图，标注哪些能力属于核心竞争力（核心域）、哪些可复用（支撑域）、哪些直接采购（通用域）。

2.2 子域划分：核心域、支撑域、通用域

DDD 将子域分为三种类型，不同类型决定了限界上下文的设计优先级与投资策略：

  • 核心域：企业竞争优势所在，须自研、深度定制。例如电商的推荐引擎。
  • 支撑域：必须存在但非核心，可适当简化。如订单状态机。
  • 通用域：行业标准能力，优先采购或使用成熟方案。如邮件通知、用户认证。
特性 核心域 支撑域 通用域
团队自主权 高（自研+持续演进） 中（可复用现有方案） 低（采购或开源）
变更频率 高（业务快速迭代） 中（随主流程变化） 低（稳定接口）
限界上下文粒度 细（可按业务活动拆分） 适中（按能力组） 粗（直接对接外部系统）
选型权衡：通用域切忌过度抽象。曾见某团队自研邮件推送服务，花费三个月迭代“富文本模板引擎”，最终发现 SendGrid 已完美解决。正确的策略是：核心域投入 70% 工程资源，支撑域 20%，通用域 ≤10%。

2.3 限界上下文：边界识别与信任链路

一个限界上下文就是一个语义与数据所有权清晰的领域模型边界。识别限界上下文的关键线索：

  • 业务事件：谁触发？谁消费？跨边界一定存在事件。
  • 组织边界：通常一个独立团队维护不超过 2 个限界上下文。
  • 数据一致性：强一致性需求的数据应放在同一限界上下文中。
  • 变化频率：不同步变化的领域模型应当拆分。

边界建立后，上下文之间通过开放主机服务（OHS）或防腐层（ACL）进行通信，形成信任链路：上游（发布者）提供稳定接口，下游（订阅者）通过 ACL 隔离领域模型差异。

伪代码示例：防腐层模式

// 下游上下文（订单）订阅上游（库存）事件
class InventoryAcl {
  on(InventoryReservedEvent event) {
    // 将库存领域的消息转换为订单领域的内部实体
    StockReservation reservation = toOrderReservation(event);
    orderRepository.save(reservation);
  }

  private StockReservation toOrderReservation(
      InventoryReservedEvent event) {
    return new StockReservation(
      event.getOrderId(),
      event.getSku(),
      event.getQuantity(),
      event.getReservedAt()
    );
  }
}

2.4 整体映射流程

从业务能力拆解到限界上下文落地的典型步骤：

  1. 事件风暴：召集业务方与技术方，贴出领域事件、命令、聚合。
  2. 划分子域：根据业务重要度与变化频率，确定核心/支撑/通用。
  3. 定义限界上下文：每个子域对应一个（或最多两个）限界上下文。
  4. 确定集成策略：事件驱动 / RPC / 批量同步，结合信任链路选型。
  5. 验证边界：检查边界内是否满足单一职责、独立部署、数据所有权。
业务域 → 系统域映射流程 业务能力拆解 订单管理 库存分配 支付处理 物流配送 用户通知 子域划分 核心域: 订单 支撑域: 库存 通用域: 支付 支撑域: 物流 通用域: 通知 限界上下文 OrderContext InventoryContext PaymentContext ShippingContext NotificationContext 核心域细粒度 通用域粗粒度 防腐层隔离

2.5 落地步骤与验收标准

落地步骤（以一次经典事件风暴工作坊为例）：

  1. 准备白板、便签、色笔；邀请业务负责人、产品经理、技术骨干。
  2. 贴出所有领域事件（橙色便签），按时间轴排列。
  3. 围绕事件贴出命令（蓝色）和聚合（黄色）。
  4. 用红色线框圈出高内聚的事件+命令+聚合，形成候选限界上下文。
  5. 评审每个上下文内的数据所有权、事务边界、对外接口。

验收标准：

维度 验收条件
完整性 所有 L2 能力组至少对应一个限界上下文
独立部署 每个限界上下文可独立发布、回滚、扩缩容
数据所有权 一个限界上下文独占其数据库（或 Schema）的写权限
团队对齐 一个团队负责的上下文不超过 2 个
集成测试 跨上下文通信均通过契约测试，无隐式依赖
常见风险点：
1. 子域划分过细：导致分布式事务爆炸、接口爆炸。建议核心域最多 3 个子域。
2. 限界上下文与团队错位：上下文数量 > 团队数 × 2 时，沟通成本陡增。
3. 忽略通用域：把通用域当作核心域投入，浪费创新资源。
4. 缺乏防腐层：不同上下文直接共享领域对象，导致强耦合。

本章完成之后，你应该能够从业务能力热力图出发，准确划分子域类型，并输出每个子域对应的限界上下文边界、集成策略与数据所有权方案。这是后续分层架构与模块职责的基础输入。

← 上一章 📖 返回目录 下一章 →