服务边界定义：DDD限界上下文在Go项目中的映射策略

在微服务架构中，最核心也最具挑战性的决策是：服务应该拆多细？ 拆得太粗，退化为单体；拆得太细，陷入分布式泥潭。DDD（领域驱动设计）的限界上下文（Bounded Context） 提供了理论依据，而Go语言的工程特性则决定了具体的映射方式。

本节将深入讲解如何将DDD的限界上下文，精准、高效地映射为Go微服务的物理边界，并给出可落地的代码组织策略。

2.1 限界上下文：微服务的“逻辑原子”

限界上下文是DDD中划分领域模型边界的核心模式。每个上下文内部拥有独立的通用语言（Ubiquitous Language） 和领域模型，上下文之间通过明确的上下文映射（Context Map） 进行集成。

2.2 Go项目中的映射策略：从逻辑到物理

在Go项目中，我们通过目录结构和包（Package）设计来物理化限界上下文。以下是三种主流策略，按推荐程度排序。

策略一：按限界上下文组织顶级目录（推荐）

这是最符合DDD精神的策略。每个顶级目录代表一个限界上下文，内部包含完整的适配层（adapter）、应用层（application）、领域层（domain） 和基础设施层（infrastructure）。

your-project/
├── cmd/                          # 可执行文件入口
│   ├── order-service/
│   │   └── main.go
│   └── payment-service/
│       └── main.go
├── internal/                     # 内部包，外部不可导入
│   ├── order/                    # 订单限界上下文
│   │   ├── domain/               # 领域层：实体、值对象、领域服务、仓储接口
│   │   │   ├── order.go
│   │   │   ├── order_repository.go
│   │   │   └── line_item.go
│   │   ├── application/          # 应用层：用例、应用服务、DTO
│   │   │   ├── create_order.go
│   │   │   └── order_dto.go
│   │   ├── adapter/              # 适配层：控制器、事件处理器、消息监听
│   │   │   ├── handler/
│   │   │   └── event/
│   │   └── infrastructure/       # 基础设施层：仓储实现、DB、外部客户端
│   │       ├── mysql/
│   │       └── payment_client/
│   └── payment/                  # 支付限界上下文
│       ├── domain/
│       ├── application/
│       ├── adapter/
│       └── infrastructure/
├── pkg/                          # 可共享的通用库
│   ├── errors/
│   └── types/
└── go.mod

策略二：按分层组织，上下文内分包

适用于团队对DDD尚不熟悉，或项目初期上下文边界不明确的场景。先按经典分层组织，在每层内部通过子包区分上下文。

your-project/
├── cmd/
│   └── main.go
├── internal/
│   ├── domain/                   # 所有领域模型
│   │   ├── order/
│   │   └── payment/
│   ├── application/              # 所有应用服务
│   │   ├── order/
│   │   └── payment/
│   ├── adapter/                  # 所有适配器
│   │   ├── handler/
│   │   └── event/
│   └── infrastructure/           # 所有基础设施
│       ├── mysql/
│       └── payment_client/
└── go.mod

策略三：按模块组织，独立go.mod（多模块仓库）

当上下文间边界非常清晰，且需要独立版本演进时，可以为每个限界上下文创建独立的Go Module。这通常用于大型项目或组织级共享的上下文。

your-project/
├── order-service/                # 独立Module
│   ├── go.mod
│   ├── cmd/
│   └── internal/
├── payment-service/              # 独立Module
│   ├── go.mod
│   ├── cmd/
│   └── internal/
├── api/                          # 共享的API定义（protobuf）
│   ├── order/
│   └── payment/
└── go.work                       # Go workspace 用于本地开发

2.3 上下文映射：Go中的集成模式

限界上下文之间需要协作。DDD定义了多种上下文映射关系，在Go中对应不同的实现模式。

上图展示了三种核心的上下文映射模式在Go中的实现：

• 防腐层（ACL）： 下游服务（订单）通过gRPC客户端调用上游服务（支付），客户端内部实现模型转换，防止上游模型污染下游领域。
• 事件发布/订阅： 库存上下文发布“库存已扣减”事件，订单上下文订阅后更新订单状态。Go中常用Kafka、RabbitMQ或NATS实现。
• 共享内核： 不推荐在微服务间共享领域实体，但可以共享值对象或事件定义，通常放在独立的 pkg/ 或 api/ 包中。

2.4 实战：在Go中实现防腐层（ACL）

防腐层是防止上下文间模型污染的关键。以下是一个订单服务调用支付服务的Go实现片段。

// internal/order/infrastructure/payment_client/acl.go
package payment_client

import (
    "context"
    "your-project/internal/order/domain" // 订单的领域模型
    pb "your-project/api/payment/v1"     // 支付服务的protobuf定义
)

// PaymentACL 是防腐层实现，将支付服务的模型转换为订单领域的模型
type PaymentACL struct {
    client pb.PaymentServiceClient
}

func NewPaymentACL(client pb.PaymentServiceClient) *PaymentACL {
    return &PaymentACL{client: client}
}

// ProcessPayment 将订单领域的支付请求转换为支付服务的gRPC调用
func (a *PaymentACL) ProcessPayment(ctx context.Context, orderID string, amount domain.Money) error {
    // 1. 转换：领域模型 -> 外部DTO
    req := &pb.CreatePaymentRequest{
        OrderId:      orderID,
        AmountCents:  amount.Cents(),
        CurrencyCode: amount.Currency(),
    }

    // 2. 调用外部服务
    resp, err := a.client.CreatePayment(ctx, req)
    if err != nil {
        return fmt.Errorf("payment acl: create payment failed: %w", err)
    }

    // 3. 转换：外部DTO -> 领域模型（如果需要）
    // 通常支付结果只需返回成功/失败，无需复杂转换
    if resp.Status != pb.PaymentStatus_SUCCESS {
        return domain.ErrPaymentFailed
    }
    return nil
}

2.5 服务边界决策清单

在实际项目中，判断一个限界上下文是否应该独立为一个微服务，可以参考以下清单：