📚 课程目录第2章服务边界设计原则

2. 服务边界设计原则：领域驱动设计(DDD)核心概念、限界上下文(Bounded Context)的定义、通用语言(Ubiquitous Language)的重要性

微服务架构的核心挑战不在于技术选型，而在于如何合理划分服务边界。错误的边界会导致服务间过度耦合、频繁的跨服务通信以及难以维护的分布式泥球。领域驱动设计（DDD）提供了一套经过验证的战略设计工具，帮助我们从业务领域出发，找到高内聚、低耦合的服务边界。

2.1 领域驱动设计(DDD)核心概念

DDD 由 Eric Evans 在其经典著作《领域驱动设计》中提出，它将软件设计的焦点从数据模型和数据库表结构转移到业务领域模型上。在微服务边界设计中，我们主要关注 DDD 的战略设计部分。

核心概念	定义	在微服务边界设计中的作用
领域 (Domain)	软件要解决的业务问题空间，即业务知识的总和。	明确系统要做什么，是边界划分的起点。
子域 (Subdomain)	对领域进行逻辑划分后的独立业务模块。分为核心子域、支撑子域、通用子域。	每个子域通常对应一个或多个微服务，是服务划分的直接依据。
限界上下文 (Bounded Context)	模型应用的显式边界，内部有统一的领域模型和通用语言。	每个限界上下文就是一个微服务或一组微服务的边界。
实体 (Entity)	具有唯一标识、生命周期会变化的对象（如订单、用户）。	定义服务内部的核心业务对象，决定数据一致性边界。
值对象 (Value Object)	没有唯一标识、只描述属性的不可变对象（如地址、金额）。	用于优化服务内部的数据结构，减少不必要的关联。
聚合 (Aggregate)	一组相关实体和值对象的集合，通过聚合根保证数据一致性。	定义事务边界，一个聚合通常在一个微服务内部完成操作。
领域事件 (Domain Event)	领域中发生的、业务人员关心的有意义的事件（如“订单已支付”）。	用于微服务之间的异步通信，实现最终一致性。

实践提示：在 Go 项目中，不要一开始就陷入实体、值对象的技术细节。先从战略设计入手，识别出核心子域和支撑子域，再逐步细化战术设计。错误的战术设计可以重构，错误的战略边界会导致灾难。

2.2 限界上下文(Bounded Context)的定义

限界上下文是 DDD 战略设计中最重要的概念。它定义了一个显式的边界，在这个边界内部，领域模型、术语、业务规则和通用语言都是一致且无歧义的。不同的限界上下文可以拥有对同一个业务概念的不同理解和模型。

例如，在电商系统中，“商品”在“商品目录上下文”中是一个包含规格、图片、描述的完整信息载体；而在“订单上下文”中，“商品”可能只是一个 ID、名称和单价。这两个上下文中的“商品”模型完全不同，但各自在其边界内都是正确的。

  核心原则：限界上下文 = 微服务边界。一个限界上下文通常对应一个独立的微服务或一组高度内聚的微服务。跨限界上下文的通信必须通过定义好的接口（API、事件、消息队列）进行，禁止直接共享数据库或领域对象。

定义限界上下文时，需要遵循以下步骤：

识别子域：与业务专家合作，将整个业务领域拆分为核心子域、支撑子域和通用子域。
寻找语言边界：观察业务团队中不同角色使用的术语是否存在歧义。当同一个词在不同场景下含义不同时，就是限界上下文的候选边界。
确定模型边界：在每个候选边界内，定义统一的领域模型。确保模型只包含该上下文关心的业务逻辑。
定义上下文映射：明确不同限界上下文之间的关系（如合作关系、客户-供应商、防腐层等）。

2.3 通用语言(Ubiquitous Language)的重要性

通用语言是 DDD 的基石。它要求开发团队、业务专家、产品经理、测试人员等所有项目参与者使用同一套语言来描述业务需求和系统行为。这套语言必须体现在代码、文档、讨论、用户故事等所有沟通媒介中。

常见反模式：业务专家说“客户取消订单”，开发人员说“将 order.status 更新为 5”。这种语言割裂会导致需求理解偏差、代码难以维护、新成员上手困难。通用语言要求代码中的类名、方法名、变量名必须与业务术语一致。

通用语言在微服务边界设计中的具体价值体现在以下三个方面：

价值维度	说明	Go 项目实践示例
消除歧义，精准划分边界	当团队对“用户”一词在不同场景下的含义达成共识时，就能准确判断哪些功能属于“用户认证上下文”，哪些属于“用户资料上下文”。	在代码中使用 `auth.User` 和 `profile.UserProfile` 区分不同上下文中的用户模型。
降低沟通成本	业务专家可以直接阅读代码中的领域逻辑，开发人员可以直接参与业务讨论，无需翻译。	Go 结构体命名直接使用业务术语：`type Order struct` 而不是 `type TbOrderInfo struct`。
驱动模型演进	当业务规则变化时，通用语言会自然引导代码模型的调整，保持设计与业务同步。	业务引入“预售订单”概念，代码中立即新增 `PreSaleOrder` 类型，而不是在 `Order` 上加一个 `IsPreSale` 字段。

在 Go 项目中落地通用语言，需要遵循以下实践：

代码即文档：接口、结构体、方法命名直接使用业务术语，避免技术性命名。
事件命名规范化：领域事件使用过去时态，如 OrderPaid、InventoryReserved。
包名映射限界上下文：每个限界上下文对应一个 Go 包，包内代码只使用该上下文的通用语言。
持续提炼：在迭代中与业务专家定期回顾术语表，确保语言一致性。

Go 代码示例：通用语言在代码中的体现

// 错误的做法：技术性命名，与业务脱节
type TbOrderInfo struct {
    ID       int64  `json:"id"`
    Status   int    `json:"status"`   // 1=待支付, 2=已支付, 3=已取消
    UserID   int64  `json:"user_id"`
    TotalAmt int64  `json:"total_amt"` // 单位：分
}

// 正确的做法：使用通用语言，业务语义清晰
type Order struct {
    ID         OrderID
    Status     OrderStatus  // 使用枚举类型：PendingPayment, Paid, Cancelled
    CustomerID CustomerID
    TotalAmount Money
}

type OrderStatus string

const (
    OrderStatusPendingPayment OrderStatus = "pending_payment"
    OrderStatusPaid           OrderStatus = "paid"
    OrderStatusCancelled      OrderStatus = "cancelled"
)