DDD 战略设计：限界上下文与子域

领域驱动设计（DDD）战略设计关注「大问题如何切」：识别子域（Subdomain）类型，并为每个核心能力划定限界上下文（Bounded Context）。

子域三分法

限界上下文的关键属性

• 统一语言（Ubiquitous Language）：上下文内术语一致；Order 里的 OrderLine 与 Inventory 里的 StockReservation 不必强行合并。
• 模型边界：实体、聚合根、仓储仅在本上下文内完整；对外只暴露 DTO / 应用服务 / 事件。
• 与部署单元的关系：理想上一上下文对应一个可独立演进的服务（或模块化单体中的一个模块），与 康威定律 对齐。

flowchart LR
  subgraph orderCtx [Order 上下文]
    O[Order 聚合]
    OL[OrderLine]
  end
  subgraph invCtx [Inventory 上下文]
    S[Sku / Stock]
    R[Reservation]
  end
  subgraph payCtx [Payment 上下文]
    P[Payment]
    Ref[Refund]
  end
  orderCtx -->|ReserveCommand API| invCtx
  orderCtx -->|InitiatePayment API| payCtx
  payCtx -->|PaymentCompleted 事件| orderCtx

按业务能力拆分 vs 按技术层拆分

架构风格：单体、SOA 与微服务 已对比分层单体与模块化单体；本节从 DDD 视角强调：微服务边界应沿业务能力（限界上下文）切，而非沿 Controller / Service / Repository 等技术层切。

两种切法对比

代码对比：集成方式

// 反例：按「层」拆服务，却共享 order 表与实体
// order-query-service 直接读 order 表 join inventory 表
@Query("SELECT o, i FROM Order o JOIN Inventory i ON ...")
List<OrderDetailDto> findAllWithStock();

// 推荐：Order 上下文通过契约调用 Inventory
public OrderView getOrder(UUID orderId) {
  Order order = orderRepo.findById(orderId);
  StockSnapshot stock = inventoryClient.getSku(order.getSkuId());
  return OrderView.from(order, stock); // 组合视图，非共享实体
}

REST 资源建模、版本化与错误码规范

限界上下文对外通常以 RESTful HTTP API 暴露能力（practice 阶段亦用 OpenFeign 消费）。好的资源建模让调用方「读 URI 即懂语义」，并预留演进空间。

资源 URI 原则

• 名词复数、表意资源：/orders、/skus/{skuId}/reservations，避免 /createOrder 动词路径。
• 动作用语义子资源或 PATCH：取消订单 POST /orders/{id}/cancel 或 PATCH /orders/{id} + {"status":"CANCELLED"}。
• 跨上下文 ID 引用：Order 只存 skuId，不在 URI 里嵌 inventory 内部仓库 ID，除非该 ID 已是稳定集成标识。
• 幂等键：写操作（如 POST /reservations）要求 Header Idempotency-Key 或 body 内 requestId，应对 部分失败 重试。

ShopFlow 核心端点（示意）

版本化策略

统一错误响应

{
  "code": "INVENTORY_INSUFFICIENT",
  "message": "SKU-1001 可售库存不足",
  "traceId": "7f3a2b1c-...",
  "details": { "skuId": "SKU-1001", "requested": 5, "available": 2 }
}

• code：机器可读、文档化枚举（各服务可前缀 ORDER_ / INV_，网关可映射为统一表）。
• traceId：与日志、链路追踪关联，便于排障。
• HTTP 状态码表达协议层语义（404 资源不存在、409 冲突、422 业务校验失败），body 的 code 表达业务层语义。

契约优先：OpenAPI 与消费者驱动契约

契约优先（Contract First）：先写 OpenAPI 规范，再生成/实现 Controller 与客户端桩代码。这样 Order 与 Inventory 团队在编码前就对齐字段、错误码与幂等语义。

OpenAPI 片段（Inventory · 预留库存）

openapi: 3.1.0
info:
  title: ShopFlow Inventory API
  version: 1.0.0
paths:
  /api/v1/reservations:
    post:
      operationId: createReservation
      parameters:
        - name: Idempotency-Key
          in: header
          required: true
          schema: { type: string, format: uuid }
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [orderId, skuId, quantity]
              properties:
                orderId: { type: string, format: uuid }
                skuId: { type: string }
                quantity: { type: integer, minimum: 1 }
      responses:
        '201':
          description: 预留成功
        '409':
          description: 库存不足或冲突

契约优先工作流

1. 领域专家 + 开发在 PR 中评审 openapi/inventory-api.yaml。
2. CI 校验 breaking change（如删除字段、改类型）。
3. 实现方对照契约写 Spring MVC / WebFlux；消费方用 OpenFeign + 生成 DTO 或手写映射。
4. 契约测试（Pact 等）在 CI 验证「消费者期望 ⊆ 提供者实现」。

消费者驱动契约（CDC）

在 微服务 集成中，调用方（消费者） 定义「我需要哪些字段与状态码」，写入契约文件；提供方 在 CI 中验证能否满足。这样 inventory 重构内部表结构时，只要仍满足 order-service 的契约，集成测试即可通过。

sequenceDiagram
  participant OC as order-service 消费者
  participant Pact as 契约仓库 / CI
  participant IS as inventory-service 提供者
  OC->>Pact: 提交期望契约（reserve 201/409）
  IS->>Pact: Provider 验证任务
  Pact->>IS: 验证通过 / 失败
  Note over OC,IS: 实现前对齐；改 API 须双方评审

ShopFlow：订单、库存、支付上下文划分

将本章方法落到 ShopFlow 全课主线：三个上下文各司其职，通过 API 网关 对外统一入口，内部走同步 API + 异步事件。

上下文职责表

下单 happy path（集成视图）

sequenceDiagram
  participant U as 用户
  participant GW as API Gateway
  participant O as order-service
  participant I as inventory-service
  participant P as payment-service
  U->>GW: POST /api/v1/orders
  GW->>O: 转发
  O->>I: POST /reservations (Idempotency-Key)
  I-->>O: 201 Reserved
  O->>P: POST /payments
  P-->>O: 202 Accepted
  O-->>U: 201 Order PENDING_PAYMENT
  P-->>O: PaymentCompleted 事件
  O->>O: 状态 → PAID

上下文映射（Context Map）简图

• Order → Inventory：Customer-Supplier（Order 为客，Inventory 为供）；Inventory 上游发布 OpenAPI，Order 消费。
• Order → Payment：同上；Payment 完成后以事件通知 Order（避免 Payment 同步回调 Order 造成环依赖）。
• Anti-corruption Layer：Order 内 InventoryClient 将外部 DTO 转为域内 ReservationResult，隔离外部模型变化。

下一章 通信模式：同步、异步与事件驱动 将把同步/异步、编排与编舞、Outbox 与本章契约映射到 Spring Cloud 概念。