4. 领域边界定义：限界上下文（Bounded Context）的识别与划分、上下文映射图

在 DDD 战略设计中，限界上下文（Bounded Context） 是划分领域边界的核心单元。它定义了模型、术语和业务逻辑的显式边界，确保每个上下文内部拥有一致且无歧义的通用语言（Ubiquitous Language）。对于后端发布拓扑而言，错误的边界划分将直接导致服务耦合、部署冲突和团队协作混乱。

4.1 限界上下文的识别原则

识别限界上下文并非单纯按功能模块切分，而是需要从业务语义、团队组织与技术约束三个维度综合判断：

4.2 上下文映射图（Context Map）

上下文映射图是描述多个限界上下文之间协作关系的战略工具。它不关注内部实现，只定义上下文之间的通信模式、数据流向与依赖强度。以下是 Go 后端发布拓扑中常见的六种映射关系：

1. 合作关系（Partnership）：两个上下文协同完成一个业务用例，需同步发布。
2. 共享内核（Shared Kernel）：共享一小部分公共模型（如值对象），变更需双方协商。
3. 客户-供应商（Customer-Supplier）：上游（供应商）决定接口，下游（客户）按需适配。
4. 遵奉者（Conformist）：下游严格遵循上游模型，不做适配层。
5. 防腐层（Anti-Corruption Layer, ACL）：下游通过适配器隔离上游模型的污染。
6. 开放主机服务（Open Host Service）：上游以明确协议（如 gRPC/HTTP API）开放能力。

4.3 限界上下文的划分步骤

在 Go 后端项目中，推荐按以下四步完成限界上下文的识别与划分：

• 步骤一：事件风暴（Event Storming） —— 与领域专家一起，识别领域事件、命令、聚合与外部系统，形成初步的上下文候选列表。
• 步骤二：术语一致性检查 —— 对每个候选上下文，检查内部术语是否唯一且无歧义。若同一术语在不同上下文中有不同含义，则必须拆分。
• 步骤三：变更频率分析 —— 统计各模块的发布频率。高频变更模块（如营销规则）与低频变更模块（如财务核算）应分属不同上下文。
• 步骤四：映射关系绘制 —— 使用上下文映射图明确上下文之间的通信模式，并确定采用同步（gRPC/HTTP）还是异步（Kafka/RabbitMQ）交互。

4.4 上下文映射图在发布拓扑中的应用

上下文映射图不仅用于设计阶段，更直接影响发布拓扑的决策：

4.5 Go 项目中的边界实现模式

在 Go 代码层面，限界上下文通常通过以下方式落地：

// 订单上下文内部：定义领域接口，不依赖外部模型
package order

// OrderRepository 是订单上下文的仓储接口
type OrderRepository interface {
    Save(order *Order) error
    FindByID(id string) (*Order, error)
}

// Order 是订单上下文的聚合根
type Order struct {
    ID        string
    Items     []OrderItem
    Status    OrderStatus
    PaymentID string // 仅引用支付上下文的 ID，不引用支付模型
}

// 防腐层：适配支付上下文的 gRPC 客户端
package order/infrastructure/acl

type PaymentACL struct {
    client pb.PaymentServiceClient
}

func (a *PaymentACL) ProcessPayment(orderID string, amount float64) (string, error) {
    resp, err := a.client.Charge(context.Background(), &pb.ChargeRequest{
        OrderId: orderID,
        Amount:  amount,
    })
    if err != nil {
        return "", err
    }
    return resp.PaymentId, nil
}