4. 限界上下文：定义、映射图与关系类型

限界上下文（Bounded Context）是 DDD 战术设计的核心单元，也是 Go 工程中划分微服务、模块、包边界的直接依据。一个限界上下文对应一个显式的业务边界，内部拥有统一的领域模型、通用语言和业务规则；边界之外，模型可以有不同的含义甚至不同的名称。

4.1 限界上下文的定义

限界上下文由 Eric Evans 在《领域驱动设计》中提出，其本质是语义边界。一个限界上下文包含：

• 领域模型：一组聚合、实体、值对象、领域服务、领域事件。
• 通用语言：团队内部使用的统一术语和沟通语言。
• 业务规则：只在该上下文内成立的不变量和约束。
• 技术实现：数据库、消息队列、API 网关等基础设施的边界。

4.2 上下文映射图

上下文映射图（Context Map）是描述多个限界上下文之间关系的可视化工具。它帮助团队理解系统全局的集成点、翻译成本和耦合程度。映射图不是架构图，而是关系图——重点在于上下文之间的连接类型，而非内部结构。

4.3 上下文之间的关系类型

DDD 定义了 9 种标准关系类型，按耦合度从高到低排列。Go 工程中常用的关系类型如下：

4.4 防腐层（ACL）的 Go 实现

防腐层是 Go 工程中最常用的关系类型之一。当订单上下文需要调用遗留的库存系统时，ACL 保护订单模型不被库存系统的数据结构污染。

// 订单上下文内部定义的接口（纯净领域模型）
type InventoryService interface {
    Reserve(ctx context.Context, sku string, qty int) error
}

// 防腐层适配器：将遗留库存系统的 HTTP API 翻译为领域接口
type LegacyInventoryAdapter struct {
    client *http.Client
    baseURL string
}

func (a *LegacyInventoryAdapter) Reserve(ctx context.Context, sku string, qty int) error {
    // 1. 将领域参数翻译为遗留系统的请求格式
    reqBody := legacyReserveRequest{
        ProductCode: sku,
        Quantity:    qty,
        WarehouseID: "default",
    }
    // 2. 调用遗留系统
    // 3. 将遗留系统的响应翻译为领域错误
    // 4. 返回领域层可理解的 error
    return nil
}

4.5 上下文关系选择矩阵

在实际 Go 项目中，选择哪种关系类型取决于以下因素：

4.6 上下文映射的 Go 工程实践

1. 显式声明边界：在 go.mod 或 internal/ 目录结构中明确每个上下文的包路径。
2. 接口隔离：上下文之间的依赖只通过接口进行，禁止直接引用内部类型。
3. 事件驱动：优先使用领域事件进行异步通信，降低时间耦合。
4. 契约测试：为上下文之间的接口编写消费者驱动契约测试（CDC），确保接口兼容性。
5. 映射图文档：将上下文映射图作为架构文档的一部分，随代码一起版本管理。