微服务

DDD通用语言在微服务协作中的作用

在领域驱动设计（DDD）中，通用语言（Ubiquitous Language） 是团队与业务专家共同构建的、贯穿业务需求、系统设计和代码实现的一致性语言。在微服务架构中，这种语言对团队内外的协作和系统一致性至关重要。以下通过一个电商系统的例子说明其作用：

场景：电商订单与库存管理

假设系统包含两个微服务：

  • 订单服务（负责创建订单、管理订单状态）
  • 库存服务（负责库存预留和扣减）

1. 团队内部的通用语言作用

问题：订单服务团队内部对“订单取消”流程的理解不一致。

  • 业务需求：用户取消订单时，需释放已预留的库存。
  • 潜在误解：
    • 开发人员A认为“取消”仅需标记订单状态为“已取消”。
    • 开发人员B认为“取消”需要同时调用库存服务的接口释放库存。

通用语言的建立：
团队通过事件风暴（Event Storming）明确以下术语：

  • 订单取消（OrderCancelled）：指用户主动取消订单，需触发两个操作：
    1. 更新订单状态为 CANCELLED
    2. 调用库存服务的 ReleaseReservedStock() 接口

作用：

  • 代码中直接体现业务术语（如 OrderCancelledEvent 事件）。
  • 测试用例描述清晰（如“当订单取消时，库存预留应被释放”）。
  • 减少团队成员间的沟通歧义，确保需求到代码的一致性。

2. 团队间的通用语言作用

问题：订单服务调用库存服务的“预留库存”接口时，双方对“预留”的定义不一致。

  • 订单服务团队认为：预留库存是暂时锁定（例如15分钟），超时未支付则自动释放。
  • 库存服务团队认为：预留库存是持久化操作，需显式调用接口释放。

通用语言的协调：
通过上下文映射（Context Mapping），两个团队协商明确：

  • 预留库存（ReserveStock）：库存服务提供接口，订单服务调用后，库存进入 RESERVED 状态，并设置超时时间（15分钟）。
  • 库存释放（ReleaseReservedStock）：订单取消或超时后，订单服务调用此接口。

作用：

  • API 接口命名与行为对齐（如 POST /reservations 和 DELETE /reservations/{id}）。
  • 跨服务边界的业务流程（如订单超时逻辑）通过事件（如 ReservationExpiredEvent）驱动。
  • 避免因术语歧义导致的库存超卖或死锁问题。

3. 通用语言的实践体现

代码与文档

  • 订单服务代码： 
    1
    2
    3
    4
    5
    6
    7
    class OrderService {
      // 方法命名直接使用业务术语
      public void cancelOrder(OrderId orderId) {
        orderRepository.markAsCancelled(orderId);
        inventoryService.releaseReservedStock(orderId); // 调用库存服务
      }
    }
  • 库存服务API文档： 
    1
    2
    3
    POST /reservations  
    请求体：{ "sku": "ABC123", "quantity": 2, "expiresIn": 900 }  
    作用：预留指定SKU的库存，900秒后自动过期。

测试用例

  • 订单服务测试： 
    1
    2
    3
    4
    Scenario: 用户取消订单后释放库存  
    When 订单 "ORD-123" 被取消  
    Then 订单状态变为 "CANCELLED"  
    And 库存服务应收到 "ReleaseReservedStock" 请求

4. 通用语言的核心价值

  1. 降低沟通成本：业务需求、技术实现、测试用例使用同一套语言，避免“翻译”错误。
  2. 明确限界上下文边界：不同微服务（如订单和库存）通过清晰的术语定义接口职责。
  3. 驱动架构设计：通过术语一致性发现领域模型中的隐含逻辑（如库存预留的时效性）。
  4. 加速新人融入：新成员通过通用语言快速理解业务规则和系统行为。

总结

通用语言是DDD在微服务落地中的粘合剂：

  • 对内：统一团队认知，确保代码反映真实业务逻辑。
  • 对外：协调跨服务交互，避免“术语鸿沟”导致的集成故障。
    最终目标是让系统设计、代码实现和业务需求保持“同频共振”。