4. 限界上下文（Bounded Context）识别：如何通过业务事件风暴识别限界上下文，以及如何在Go项目中用模块（module）或包（package）映射限界上下文

在领域驱动设计（DDD）中，限界上下文（Bounded Context）是划分系统边界、隔离业务逻辑的核心单元。它定义了模型应用的显式边界，每个上下文内部拥有统一的语言（Ubiquitous Language）和独立的领域模型。在微服务和云原生架构中，限界上下文通常直接映射为一个独立的服务或模块。

本章将介绍如何通过业务事件风暴（Event Storming）这一协作建模技术识别限界上下文，并展示在Go项目中如何用Go Module和Package结构精确映射这些上下文边界。

4.1 业务事件风暴：识别限界上下文的核心方法

事件风暴是一种由Alberto Brandolini提出的工作坊式建模技术，通过跨职能团队（业务专家、开发、测试、运维）的协作，快速发现业务事件、命令、聚合和限界上下文。其核心产出物是一张覆盖完整业务流程的事件流图。

4.1.1 事件风暴的基本元素

元素类型 颜色（通常） 描述 示例
领域事件（Domain Event） 橙色 业务中已经发生的、不可改变的事实 订单已创建、支付已确认
命令（Command） 蓝色 触发领域事件的用户意图或系统指令 提交订单、发起支付
聚合（Aggregate） 黄色 具有事务一致性的领域对象集群 订单、用户账户
外部系统（External System） 粉色 与当前系统交互的第三方服务 支付网关、物流API
用户/角色（Actor） 绿色 发起命令的人或系统 买家、客服、定时任务
限界上下文（Bounded Context） 灰色/虚线框 将相关事件、命令、聚合归组的边界 订单上下文、支付上下文

4.1.2 事件风暴的典型步骤

  1. 准备阶段：准备一面足够大的墙（物理或虚拟白板），准备不同颜色的便利贴。
  2. 发散事件：团队自由写出所有能想到的领域事件（橙色），按时间线从左到右排列。
  3. 补充命令与角色：在每个事件左侧贴上触发它的命令（蓝色）和角色（绿色）。
  4. 识别聚合：将紧密相关的事件和命令归入同一个聚合（黄色），聚合是事务一致性的最小单元。
  5. 划分限界上下文：观察聚合之间的耦合度和通信频率，将高内聚的聚合群组划入同一个限界上下文。
  6. 标记上下文映射：在上下文之间画出关系线（如合作关系、共享内核、客户-供应商等）。
实践建议：在事件风暴中，不要过早陷入技术细节。先关注“发生了什么”和“谁触发了它”，限界上下文的边界会在事件流自然聚集的地方浮现出来。

4.2 从事件风暴到限界上下文：一个电商案例

假设我们为一个电商平台进行事件风暴，部分事件流如下：

用户提交订单 → 订单已创建 → 支付网关扣款 → 支付已确认 → 仓库分配库存 → 库存已锁定 → 物流生成运单 → 订单已发货

通过分析事件之间的业务归属和数据一致性要求，我们可以识别出以下限界上下文：

  • 订单上下文（Order Context）：负责订单创建、状态管理、订单查询。包含聚合：订单、订单项。
  • 支付上下文（Payment Context）：负责支付请求、与支付网关交互、退款处理。包含聚合：支付交易、退款单。
  • 库存上下文（Inventory Context）：负责库存锁定、释放、库存查询。包含聚合：库存、库存流水。
  • 物流上下文（Logistics Context）：负责运单生成、物流状态跟踪。包含聚合：运单、物流轨迹。
关键判断标准：如果两个聚合需要强事务一致性（ACID），它们应该属于同一个限界上下文；如果只需要最终一致性（通过事件驱动），则可以分属不同上下文。

4.3 在Go项目中映射限界上下文

Go语言提供了Module和Package两级代码组织单元，非常适合映射限界上下文。推荐采用按上下文拆分Module的策略，每个限界上下文对应一个独立的Go Module。

4.3.1 项目结构示例

以下是一个电商系统的Go项目结构，每个限界上下文都是一个独立的Module：

ecommerce-platform/
├── go.work                  # Go workspace，统一管理多个Module
├── order-context/           # 订单上下文（独立Module）
│   ├── go.mod
│   ├── cmd/
│   │   └── order-service/   # 服务入口
│   ├── internal/
│   │   ├── domain/          # 领域模型（聚合、实体、值对象）
│   │   ├── application/     # 应用服务（用例编排）
│   │   └── infrastructure/  # 基础设施（数据库、消息队列）
│   └── api/                 # 对外接口（gRPC/HTTP）
├── payment-context/         # 支付上下文
│   ├── go.mod
│   ├── cmd/
│   ├── internal/
│   └── api/
├── inventory-context/       # 库存上下文
│   ├── go.mod
│   └── ...
├── logistics-context/       # 物流上下文
│   ├── go.mod
│   └── ...
└── shared-kernel/           # 共享内核（可选，跨上下文共享的值对象）
    ├── go.mod
    └── types/               # 如 Money、Address 等

4.3.2 使用Go Workspace管理多Module

Go 1.18引入的Workspace功能使得在本地开发时同时处理多个Module变得简单。在项目根目录创建go.work文件：

go 1.22

use (
    ./order-context
    ./payment-context
    ./inventory-context
    ./logistics-context
    ./shared-kernel
)

这样，在任何一个Module中都可以直接引用其他Module的代码，而无需发布到远程仓库。

4.3.3 上下文之间的依赖关系

限界上下文之间的依赖应遵循单向依赖原则。例如，订单上下文可以依赖共享内核，但不应直接依赖支付上下文的内部实现。上下文之间的通信通过接口或事件进行。

源上下文 目标上下文 通信方式 Go实现
订单上下文 支付上下文 事件驱动（最终一致性） 消息队列（如Kafka、RabbitMQ）
订单上下文 库存上下文 事件驱动 消息队列
订单上下文 物流上下文 事件驱动 消息队列
支付上下文 共享内核 直接依赖（值对象） Go Module导入

4.4 限界上下文映射的Go代码示例

以下展示订单上下文内部如何组织代码，以及如何通过接口定义与支付上下文的边界。

4.4.1 订单上下文内部结构

// order-context/internal/domain/order.go
package domain

import "time"

type OrderID string

type Order struct {
    ID        OrderID
    UserID    string
    Items     []OrderItem
    Status    OrderStatus
    CreatedAt time.Time
}

type OrderItem struct {
    ProductID string
    Quantity  int
    Price     Money
}

type OrderStatus string

const (
    OrderStatusPending   OrderStatus = "pending"
    OrderStatusPaid      OrderStatus = "paid"
    OrderStatusShipped   OrderStatus = "shipped"
    OrderStatusCancelled OrderStatus = "cancelled"
)

4.4.2 定义上下文边界接口

// order-context/internal/domain/payment_port.go
// 支付上下文对外提供的接口（在订单上下文中定义）
package domain

type PaymentService interface {
    // RequestPayment 发起支付请求，返回支付交易ID
    RequestPayment(orderID OrderID, amount Money) (string, error)
    // GetPaymentStatus 查询支付状态
    GetPaymentStatus(transactionID string) (string, error)
}

4.4.3 应用服务中调用接口

// order-context/internal/application/order_service.go
package application

import (
    "context"
    "order-context/internal/domain"
)

type OrderService struct {
    orderRepo      domain.OrderRepository
    paymentService domain.PaymentService
}

func (s *OrderService) PlaceOrder(ctx context.Context, cmd PlaceOrderCommand) error {
    // 1. 创建订单聚合
    order := domain.NewOrder(cmd.UserID, cmd.Items)
    
    // 2. 持久化订单
    if err := s.orderRepo.Save(ctx, order); err != nil {
        return err
    }
    
    // 3. 调用支付接口（通过领域接口，不直接依赖支付上下文实现）
    transactionID, err := s.paymentService.RequestPayment(order.ID, order.TotalAmount())
    if err != nil {
        return err
    }
    
    // 4. 记录支付交易ID到订单
    order.SetTransactionID(transactionID)
    return s.orderRepo.Update(ctx, order)
}
注意：在Go中，限界上下文之间的依赖应通过接口定义在调用方的领域层，而不是被调用方。这符合依赖倒置原则（DIP），确保领域层不依赖基础设施。

4.5 限界上下文识别与映射的常见误区

  • 误区一：按技术分层划分上下文（如controller层、service层、dao层）。
    正确做法：按业务能力划分，每个上下文包含完整的技术栈。
  • 误区二：上下文粒度过细（每个实体一个上下文）。
    正确做法：上下文应包含高内聚的聚合群，通常一个微服务对应1-3个上下文。
  • 误区三：共享数据库。不同上下文直接访问同一张表。
    正确做法：每个上下文拥有独立的数据库模式，通过API或事件交换数据。
  • 误区四：在Go中使用单一Module，所有代码放在一个仓库的同一个Module下。
    正确做法：使用多Module + Workspace，强制代码边界。

4.6 本章小结

通过业务事件风暴识别限界上下文，是DDD落地微服务架构的关键步骤。在Go项目中，利用Go Module和Workspace可以精确、优雅地映射这些业务边界。记住：限界上下文是业务概念，Module是代码映射，两者之间的对齐程度直接决定了项目的可维护性和演进能力。

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