1. 领域驱动设计概述：DDD核心概念、战略设计与战术设计、Go语言与DDD的契合点

1.1 什么是领域驱动设计？

领域驱动设计（Domain-Driven Design，简称 DDD）是一种软件设计方法论，由 Eric Evans 在其 2003 年的经典著作《Domain-Driven Design: Tackling Complexity in the Heart of Software》中系统提出。DDD 的核心主张是：软件系统的复杂性与业务领域的复杂性直接相关，因此软件设计的重心应始终围绕业务领域本身，而非技术实现细节。

DDD 提供了一套完整的思维模型和实践工具，帮助开发团队与领域专家使用统一的语言（通用语言）进行沟通，并通过分层架构将领域逻辑与技术基础设施解耦。它特别适合处理具有复杂业务规则、多变需求或长期演进的系统。

适用场景提示：DDD 并非银弹。它最适合业务逻辑复杂、规则多变、需要长期维护的中大型系统。对于简单的 CRUD 应用或原型验证阶段，过度使用 DDD 可能带来不必要的设计成本。

1.2 DDD 核心概念速览

DDD 包含一组紧密关联的核心概念，它们构成了理解和实践 DDD 的基础。下表列出了最重要的概念及其简要说明：

概念 类别 简要说明
领域（Domain） 问题空间 软件所要解决的核心业务范围，例如电商系统的“订单管理”、“库存管理”。
子域（Subdomain） 问题空间 对领域进行细分，分为核心子域、支撑子域和通用子域。
通用语言（Ubiquitous Language） 协作工具 团队（开发、产品、业务）共同使用的、无歧义的业务术语体系。
限界上下文（Bounded Context） 解决方案空间 通用语言和模型生效的显式边界，每个上下文内部保持模型一致性。
实体（Entity） 战术建模 具有唯一标识、生命周期内状态可变的领域对象（如用户、订单）。
值对象（Value Object） 战术建模 通过属性值定义、不可变、无唯一标识的对象（如金额、地址）。
聚合（Aggregate） 战术建模 一组相关对象的集群，通过聚合根保证数据一致性和事务边界。
领域事件（Domain Event） 战术建模 领域中发生的、业务人员关心的有意义的事件（如“订单已支付”）。
仓储（Repository） 基础设施 提供聚合的持久化与检索接口，隐藏底层存储实现。
领域服务（Domain Service） 战术建模 处理无法自然归属于实体或值对象的领域逻辑（如“转账”）。

1.3 战略设计与战术设计

DDD 将设计活动分为两个层次：战略设计和战术设计。两者关注不同粒度的问题，但相互依赖、缺一不可。

1.3.1 战略设计（Strategic Design）

战略设计关注系统的宏观结构，回答“系统应该分成哪些部分”以及“各部分之间如何协作”。其核心产出包括：

  • 领域划分：识别核心子域、支撑子域和通用子域，明确投资优先级。
  • 限界上下文识别：划定每个模型的边界，确保模型内部高内聚、上下文之间低耦合。
  • 上下文映射（Context Map）：定义不同限界上下文之间的集成关系（如防腐层、开放主机服务、发布语言等）。
战略设计核心原则：每个限界上下文内部使用统一的通用语言；上下文之间通过明确的接口或事件进行通信，避免模型泄漏。

1.3.2 战术设计（Tactical Design）

战术设计关注限界上下文内部的微观实现，回答“如何用代码表达领域模型”。它提供了一组具体的建模模式：

  • 实体（Entity）：拥有唯一标识，状态可变。
  • 值对象（Value Object）：不可变，通过属性值定义相等性。
  • 聚合（Aggregate）：由聚合根统一管理，保证事务一致性。
  • 领域事件（Domain Event）：记录业务状态变更，用于解耦上下文。
  • 领域服务（Domain Service）：承载跨实体或值对象的业务逻辑。
  • 仓储（Repository）：提供聚合的持久化接口。
  • 工厂（Factory）：封装复杂对象的创建逻辑。

下表对比了战略设计与战术设计的核心差异：

维度 战略设计 战术设计
关注粒度 系统级、模块级 类级、方法级
核心产出 限界上下文、上下文映射 实体、值对象、聚合、领域事件
主要参与者 架构师、领域专家、技术负责人 开发工程师、领域专家
变更频率 较低，架构级决策 较高，随业务迭代演进
与代码的关系 指导代码组织结构 直接映射为代码实现

下图展示了战略设计与战术设计在 DDD 实践中的整体关系：

DDD 战略设计与战术设计关系图 战略设计层（宏观） 关注：系统边界划分、上下文集成、投资优先级 产出：限界上下文、上下文映射、通用语言 参与者：架构师 + 领域专家 + 技术负责人 战术设计层（微观） 关注：限界上下文内部的领域模型实现 产出：实体、值对象、聚合、领域事件、仓储 参与者：开发工程师 + 领域专家 模式：Entity、Value Object、Aggregate、Domain Service 指导与约束 战略设计为战术设计划定边界，战术设计通过代码实现验证战略决策的正确性

1.4 Go 语言与 DDD 的契合点

Go 语言（Golang）自 2009 年诞生以来，凭借其简洁的语法、高效的并发模型和出色的工程化能力，在微服务、云原生和后端系统领域占据了重要地位。Go 的设计哲学与 DDD 的实践原则存在多处天然契合：

1.4.1 契合点一览

DDD 原则 / 模式 Go 语言特性 契合说明
通用语言 简洁命名、无继承 Go 鼓励使用短而精确的标识符，强制显式错误处理，有助于在代码中直接体现业务术语。
限界上下文 包（package）机制 Go 的包是天然的模块化边界，通过 internal 目录可以严格限制包外访问，完美对应限界上下文。
实体与值对象 结构体（struct） Go 的结构体可以清晰表达实体（带标识）和值对象（不可变、无标识），且值对象可通过值传递实现不可变性。
聚合 组合（composition） Go 推崇组合优于继承，聚合根通过组合子实体和值对象形成完整的业务一致性边界。
仓储接口 接口（interface） Go 的接口是隐式实现，仓储接口可以定义在领域层，而具体实现在基础设施层，实现依赖反转。
领域事件 channel + goroutine Go 的并发原语天然适合实现事件发布/订阅模式，领域事件可以异步、高效地在上下文之间传播。
依赖反转 接口 + 构造函数注入 Go 通过接口定义依赖，构造函数接收接口参数，轻松实现领域层对基础设施层的解耦。

1.4.2 Go 实现 DDD 的典型分层架构

在 Go 项目中实践 DDD，通常采用四层架构（或变体），各层职责清晰，依赖方向由外向内：

Go 语言 DDD 四层架构 接口层（Interface / Handler） HTTP Handler、gRPC 服务、消息队列消费者 应用层（Application / Use Case） 编排领域对象、事务管理、DTO 转换 领域层（Domain） 实体、值对象、聚合、领域服务、仓储接口、领域事件 基础设施层（Infrastructure） 数据库实现、缓存、消息队列客户端、外部 API 适配器 调用 调用 实现

1.4.3 一个简单的 Go 领域模型示例

以下代码片段展示了如何在 Go 中表达一个简单的“订单”聚合，包含实体、值对象和仓储接口：

// 文件：domain/order/entity.go
package order

import (
    "time"
    "github.com/google/uuid"
)

// OrderID 是订单实体的唯一标识（值对象）
type OrderID string

// Money 是金额值对象（不可变）
type Money struct {
    Amount   float64
    Currency string
}

// OrderItem 是订单项值对象
type OrderItem struct {
    ProductID string
    Quantity  int
    UnitPrice Money
}

// Order 是聚合根实体
type Order struct {
    ID        OrderID
    CustomerID string
    Items     []OrderItem
    Total     Money
    Status    string
    CreatedAt time.Time
}

// NewOrder 是订单工厂方法
func NewOrder(customerID string, items []OrderItem) (*Order, error) {
    // 领域校验逻辑
    if len(items) == 0 {
        return nil, ErrEmptyOrder
    }
    // 计算总价
    var total float64
    for _, item := range items {
        total += item.UnitPrice.Amount * float64(item.Quantity)
    }
    return &Order{
        ID:         OrderID(uuid.New().String()),
        CustomerID: customerID,
        Items:      items,
        Total:      Money{Amount: total, Currency: "CNY"},
        Status:     "pending",
        CreatedAt:  time.Now(),
    }, nil
}

// 文件：domain/order/repository.go
package order

// OrderRepository 是仓储接口，定义在领域层
type OrderRepository interface {
    Save(order *Order) error
    FindByID(id OrderID) (*Order, error)
    Delete(id OrderID) error
}
实践注意：Go 的 internal 包机制是实施限界上下文的有力工具。将领域模型放在 internal/domain 下，可以确保外部包无法直接访问领域内部细节，强制通过应用层或接口层进行交互。

1.5 本章小结

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