4. 领域边界与限界上下文：如何用DDD划分微服务边界，识别事务边界

在分布式系统中，微服务边界的划分直接决定了事务的复杂度与一致性成本。领域驱动设计（DDD）通过限界上下文（Bounded Context）这一核心模式，为服务拆分提供了严谨的语义边界，同时也为事务边界的识别提供了可操作的依据。

4.1 限界上下文：微服务边界的语义锚点

限界上下文是DDD中最重要的战术模式之一。它定义了一个显式的边界，在边界内部，领域模型具有统一的含义和规则；边界外部，模型可以有不同的解释甚至完全不同的结构。

概念 说明 微服务映射
限界上下文 模型语义一致的显式边界 通常对应一个微服务或一个模块
通用语言 团队内部统一使用的业务术语 服务接口、事件、DTO 的命名规范
上下文映射 不同限界上下文之间的关系 服务间通信模式（RPC/事件/共享内核）
聚合 事务一致性的最小单元 数据库事务边界、缓存失效范围
实践要点：一个限界上下文内部，所有模型变更必须保持事务一致性；跨限界上下文的变更，必须通过最终一致性或Saga模式处理。

4.2 事务边界识别：从聚合到限界上下文

事务边界的识别遵循“由内向外”的层次递进：

  1. 聚合边界：一个聚合内的所有实体和值对象必须在一个数据库事务中完成变更。
  2. 限界上下文边界：同一个限界上下文内的多个聚合，如果业务要求强一致性，可以放在同一个本地事务中；否则应使用领域事件解耦。
  3. 服务边界：跨限界上下文的操作，必须采用分布式事务模式（如Saga、TCC、事件驱动）。
核心原则：聚合是事务一致性的最小单元，限界上下文是最终一致性的默认边界。

4.3 上下文映射关系与事务策略

不同的上下文映射关系，对应不同的事务处理策略：

映射关系 通信方式 推荐事务策略 适用场景
合作关系 事件/消息 最终一致性 + 补偿 订单与库存
共享内核 共享库/数据库 本地事务（强一致） 用户与权限
客户-供应商 REST/gRPC Saga 或 TCC 支付与账务
分离方式 无直接通信 无事务需求 独立子系统

4.4 领域边界与事务边界的映射关系

下图展示了从业务领域到微服务、再到事务边界的完整映射链路：

领域边界 → 微服务边界 → 事务边界映射 业务域 订单域 库存域 支付域 物流域 限界上下文 订单上下文 库存上下文 支付上下文 物流上下文 微服务 order-svc inventory-svc payment-svc logistics-svc 事务边界识别规则 1. 聚合内部：强一致性（本地事务） 2. 限界上下文内部：优先本地事务，必要时使用领域事件 3. 跨限界上下文：必须使用 Saga / TCC / 事件驱动 4. 事务边界 = 聚合边界 ∪ 限界上下文边界 ∪ 服务边界 ⚠ 错误示例：跨限界上下文使用分布式事务（XA）会导致性能瓶颈与耦合

4.5 实战案例：电商订单创建的事务边界划分

以电商下单流程为例，展示如何基于DDD划分事务边界：

步骤 操作 所属限界上下文 事务策略
1 创建订单（Order聚合） 订单上下文 本地事务（强一致）
2 扣减库存（Inventory聚合） 库存上下文 本地事务（强一致）
3 发送“订单已创建”事件 订单上下文 → 库存上下文 最终一致性（事件总线）
4 库存扣减成功后发送“库存已扣减”事件 库存上下文 → 支付上下文 最终一致性（事件总线）
5 发起支付（Payment聚合） 支付上下文 Saga（补偿事务）
常见误区：不要试图用一个分布式事务跨越订单、库存、支付三个限界上下文。正确的做法是使用Saga模式，每个步骤在各自限界上下文内完成本地事务，失败时通过补偿操作回滚。

4.6 Go语言实现：限界上下文内的聚合事务

以下代码展示如何在Go中实现一个限界上下文内的聚合事务：

// order.go - 订单聚合根
type Order struct {
    ID        string
    Items     []OrderItem
    Status    OrderStatus
    CreatedAt time.Time
}

// order_repository.go - 仓储接口
type OrderRepository interface {
    Save(ctx context.Context, order *Order) error
    FindByID(ctx context.Context, id string) (*Order, error)
}

// order_service.go - 领域服务（事务边界）
type OrderService struct {
    repo OrderRepository
    db   *sql.DB // 限界上下文内的数据库连接
}

func (s *OrderService) CreateOrder(ctx context.Context, items []OrderItem) (*Order, error) {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return nil, err
    }
    defer tx.Rollback() // 确保异常时回滚

    order := &Order{
        ID:        uuid.New().String(),
        Items:     items,
        Status:    OrderStatusPending,
        CreatedAt: time.Now(),
    }

    // 聚合内部校验（强一致性）
    if err := order.Validate(); err != nil {
        return nil, err
    }

    // 保存聚合（本地事务）
    if err := s.repo.Save(ctx, order); err != nil {
        return nil, err
    }

    // 提交事务
    if err := tx.Commit(); err != nil {
        return nil, err
    }

    // 发布领域事件（最终一致性）
    event := OrderCreatedEvent{OrderID: order.ID, Items: order.Items}
    go s.eventBus.Publish(ctx, event)

    return order, nil
}

4.7 限界上下文与事务边界的匹配矩阵

下表总结了不同场景下的最佳实践：

场景 限界上下文数量 推荐事务模式 一致性级别
单体应用内部 1 本地事务 强一致
同一限界上下文内多个聚合 1 本地事务 或 领域事件 强一致 / 最终一致
跨限界上下文（同步） 2+ Saga / TCC 最终一致
跨限界上下文（异步） 2+ 事件驱动 + 补偿 最终一致
跨系统（外部服务） N/A Saga + 幂等 最终一致

4.8 本章小结

  • 限界上下文是微服务边界的语义基础，也是事务边界的首要划分依据。
  • 聚合是事务一致性的最小单元，一个聚合内的所有变更必须在一个本地事务中完成。
  • 跨限界上下文的操作必须采用最终一致性模式，避免分布式事务带来的性能与复杂度问题。
  • 在Go中，通过database/sql的BeginTx实现聚合内的本地事务，通过事件总线实现跨上下文的最终一致性。
← 上一章 📖 返回目录 下一章 →