2、领域驱动设计基础：什么是领域边界，限界上下文（Bounded Context）的概念，实体与值对象的区别

领域驱动设计（Domain-Driven Design，DDD）是一套应对复杂业务建模的方法论。在微服务与API架构中，DDD的核心价值在于：它帮助团队找到正确的领域边界，从而设计出高内聚、低耦合的接口与模块。本章将围绕三个基础概念展开：领域边界、限界上下文（Bounded Context）、实体（Entity）与值对象（Value Object）的区别。

2.1 领域边界：问题空间的切割线

领域边界是DDD中最先需要明确的“物理墙”。它定义了某个业务问题空间的范围，以及在这个范围内哪些概念、规则和术语是有效的。超出边界，概念的含义可能发生变化，甚至完全失效。

维度 说明 示例（电商系统）
问题空间 业务要解决的现实问题集合 商品展示、下单、支付、物流
领域边界 将问题空间划分为独立子域的分界线 订单域、支付域、库存域
通用语言 边界内团队与业务专家共享的术语 订单域内“订单”包含商品明细、金额、状态
实践要点：领域边界不是技术分层（如Controller/Service/DAO），而是业务语义的聚合。在Go项目中，一个领域边界通常对应一个独立的internal/domain/xxx包。

2.2 限界上下文（Bounded Context）：边界的实现载体

限界上下文是领域边界在代码和模型层面的显式表达。它规定了：

  • 模型只在其上下文内有效；
  • 上下文之间通过上下文映射（Context Map）进行通信；
  • 每个上下文拥有独立的通用语言、实体定义和业务规则。

以下SVG图展示了电商系统中三个典型的限界上下文及其关系：

电商系统限界上下文示例 电商系统限界上下文（Bounded Context）示例 订单上下文 实体：订单、订单项 值对象：金额、地址 服务：下单、取消 通用语言：订单、支付单 支付上下文 实体：支付单、交易流水 值对象：支付方式、金额 服务：支付、退款 通用语言：支付单、交易号 库存上下文 实体：库存记录、仓库 值对象：库存量、SKU 服务：扣减、回滚 通用语言：库存、预占 说明：每个限界上下文拥有独立的通用语言和模型。订单上下文中的“金额”是值对象， 支付上下文中的“金额”也是值对象，但它们的业务含义和校验规则可能不同。 上下文映射：订单 → 支付（事件驱动），订单 → 库存（RPC/消息）
关键原则：限界上下文是微服务拆分的直接依据。在Go项目中，一个限界上下文通常对应一个独立的Go Module或internal下的顶级包。跨上下文的API调用必须通过明确的接口层（如gRPC、REST）进行，不允许直接访问内部模型。

2.3 实体（Entity）与值对象（Value Object）

实体和值对象是领域模型中最基本的两种对象类型。它们的核心区别在于：实体拥有唯一标识且会经历生命周期变化；值对象只描述某个属性集合，没有独立标识，且不可变。

对比维度 实体（Entity） 值对象（Value Object）
唯一标识 有（如ID、UUID） 无，由属性值定义相等性
可变性 可变（属性可更新） 不可变（替换而非修改）
生命周期 有独立生命周期 无生命周期，随实体创建/销毁
相等性判断 通过ID判断 通过所有属性值判断
典型示例 用户、订单、商品 金额、地址、颜色、时间段
Go实现风格 struct + 指针接收者方法 struct + 值接收者 + 无setter

以下SVG图直观对比了实体与值对象在建模时的差异：

实体与值对象对比图 实体 vs 值对象：建模对比 实体：订单（Order） ID: order-2024-001 (唯一标识) Status: pending → paid → shipped (可变) Items: []OrderItem (包含值对象) TotalAmount: Money{100, "CNY"} (值对象) 方法：Pay()、Cancel()、Ship() → 改变状态 值对象：金额（Money） Amount: 100.00 (不可变) Currency: "CNY" (不可变) Equals: 比较所有字段 (无ID) Replace: 新值 = Money{200, "CNY"} 方法：Add()、Subtract() → 返回新实例 包含 核心规则：实体用ID跟踪变化，值对象用值定义相等性。值对象应设计为不可变，修改时创建新实例。

2.4 Go代码中的实体与值对象实现

在Go项目中，实体和值对象的实现风格有明显差异。以下代码展示了典型实现：

// 实体：订单（Order）
type Order struct {
    ID          string    // 唯一标识
    CustomerID  string
    Status      OrderStatus
    Items       []OrderItem
    TotalAmount Money     // 值对象
    CreatedAt   time.Time
}

// 实体方法：修改状态（可变）
func (o *Order) Pay() error {
    if o.Status != OrderStatusPending {
        return errors.New("order can only be paid when pending")
    }
    o.Status = OrderStatusPaid
    return nil
}

// 值对象：金额（Money）
type Money struct {
    Amount   float64
    Currency string
}

// 值对象方法：返回新实例（不可变）
func (m Money) Add(other Money) (Money, error) {
    if m.Currency != other.Currency {
        return Money{}, errors.New("currency mismatch")
    }
    return Money{Amount: m.Amount + other.Amount, Currency: m.Currency}, nil
}

// 值对象相等性判断
func (m Money) Equals(other Money) bool {
    return m.Amount == other.Amount && m.Currency == other.Currency
}
常见陷阱：
  • 将值对象设计为可变（如提供SetAmount方法）—— 违反不可变原则，可能导致共享引用问题；
  • 在实体中使用==直接比较值对象指针 —— 应使用值对象的Equals方法；
  • 跨限界上下文复用同一个实体定义 —— 每个上下文应有自己的实体版本。

2.5 领域边界、限界上下文与API设计的关系

理解这三个概念对API架构师至关重要，因为它们直接决定了：

  • API的粒度：一个限界上下文通常对应一个微服务，其对外暴露的API就是该上下文的“防腐层”；
  • 模型的版本管理：不同限界上下文中的同一概念（如“用户”）可能以不同版本演进；
  • OpenAPI规范的组织：每个限界上下文应有独立的OpenAPI文档，文档内的schema对应上下文内的实体和值对象。
← 上一章 📖 返回目录 下一章 →