2. 服务边界划分原则：领域驱动设计(DDD)简介、限界上下文(Bounded Context)概念、实体与值对象区分

微服务架构的核心挑战在于如何合理划分服务边界。错误的边界划分会导致服务间过度耦合、频繁的跨服务调用以及数据一致性难题。领域驱动设计（Domain-Driven Design，DDD） 提供了一套系统化的方法论，帮助我们从业务领域出发，识别出高内聚、低耦合的微服务边界。

2.1 领域驱动设计（DDD）简介

DDD 由 Eric Evans 在其著作《领域驱动设计：软件核心复杂性应对之道》中提出，强调以业务领域为核心驱动软件设计。其核心理念是：

  • 业务优先：技术实现应服务于业务模型，而非反过来。
  • 统一语言（Ubiquitous Language）：开发团队、业务专家、产品经理使用同一套术语沟通，这些术语直接体现在代码中。
  • 模型驱动设计：通过实体、值对象、聚合、领域服务等模式，将复杂的业务逻辑封装在领域模型中。
实践提示： 在微服务拆分初期，建议组织业务专家与开发团队进行“事件风暴（Event Storming）”工作坊，快速梳理核心业务流程与关键领域事件，这是落地 DDD 的高效起点。

2.2 限界上下文（Bounded Context）概念

限界上下文是 DDD 中最重要的战略设计模式。它定义了领域模型的边界，在这个边界内部，统一语言和模型是完整且一致的；边界之外，模型可以有不同的含义或实现。

每个限界上下文通常对应一个独立的微服务或子系统。下表展示了电商系统中不同限界上下文的典型划分：

限界上下文 核心职责 典型模型 对外接口
订单上下文 订单创建、状态流转、履约 订单、订单项、支付记录 REST API / 事件
库存上下文 库存管理、出入库、锁定 库存、仓库、库存流水 REST API / 消息队列
支付上下文 支付处理、退款、对账 支付单、交易流水、账户 REST API / 事件
用户上下文 用户注册、认证、权限 用户、角色、权限 REST API / gRPC

下图展示了限界上下文之间的典型协作关系：

限界上下文协作关系图 订单上下文 Order Service 统一语言：订单、支付单 库存上下文 Inventory Service 统一语言：库存、SKU 支付上下文 Payment Service 统一语言：交易、退款 关键原则： 1. 每个限界上下文拥有独立的数据库、代码库和部署单元。 2. 上下文之间通过事件（Event）或 API 进行异步/同步通信。 3. 同一个业务概念（如“用户”）在不同上下文中可以有不同的属性集合。

2.3 实体与值对象区分

在限界上下文内部，领域模型由实体（Entity）和值对象（Value Object，VO）构成。正确区分两者是建模的基础。

实体（Entity）

  • 具有唯一标识：即使所有属性相同，只要 ID 不同，就是不同的对象。
  • 可变（Mutable）：实体的属性可以随时间变化，但其身份保持不变。
  • 生命周期管理：通常通过仓储（Repository）进行持久化。

值对象（Value Object）

  • 无唯一标识：完全由属性值定义，两个值对象如果所有属性相同，则视为同一个对象。
  • 不可变（Immutable）：创建后不允许修改，修改时通常返回新实例。
  • 可共享：可以在多个实体之间安全共享，无需担心副作用。
判断口诀： 问自己“这个对象如果丢失了 ID，还能区分吗？”——能区分则是值对象，不能区分则是实体。

下表对比了实体与值对象的核心差异：

维度 实体（Entity） 值对象（Value Object）
标识 有唯一标识（如 ID、UUID） 无标识，由属性值定义
可变性 可变（Mutable） 不可变（Immutable）
相等性 按标识判断 按所有属性值判断
生命周期 有独立生命周期，需持久化 无独立生命周期，通常作为实体属性存在
典型例子 订单、用户、商品 地址、金额、时间段、颜色

下面通过一个代码示例展示实体与值对象的实现差异：

// 实体：订单（Order）
public class Order {
    private String orderId;      // 唯一标识
    private String customerId;
    private Money totalAmount;   // 值对象
    private OrderStatus status;  // 值对象（枚举）
    private List<OrderItem> items;

    // 实体允许修改状态
    public void changeStatus(OrderStatus newStatus) {
        this.status = newStatus;
    }
}

// 值对象：金额（Money）
public final class Money {
    private final BigDecimal amount;
    private final String currency;

    // 构造时校验
    public Money(BigDecimal amount, String currency) {
        if (amount == null || currency == null) {
            throw new IllegalArgumentException("金额和币种不能为空");
        }
        this.amount = amount;
        this.currency = currency;
    }

    // 不可变：加法返回新对象
    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new IllegalArgumentException("币种不一致");
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }

    // 按值相等
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Money)) return false;
        Money money = (Money) o;
        return amount.equals(money.amount) && currency.equals(money.currency);
    }

    @Override
    public int hashCode() {
        return Objects.hash(amount, currency);
    }
}
常见误区： 将值对象设计为可变对象，或者为值对象生成数据库主键 ID。这会导致模型混乱，丧失值对象的共享安全性和不可变优势。值对象应直接作为实体属性嵌入，而非独立建表。

下图展示了实体与值对象在领域模型中的组合关系：

实体与值对象组合关系 Order（实体） - orderId: String - customerId: String - totalAmount: Money - status: OrderStatus Money（值对象） - amount: BigDecimal - currency: String OrderStatus（值对象） - code: String 实体包含 值对象作为 属性

2.4 小结

  • DDD 提供了以业务领域为中心的建模方法论，统一语言是团队协作的基石。
  • 限界上下文 是微服务划分的直接依据，每个上下文内部保持模型一致性，上下文之间通过事件或 API 解耦。
  • 实体 有唯一标识且可变，值对象 无标识且不可变，正确区分两者能显著提升领域模型的清晰度和可维护性。
← 上一章 📖 返回目录 下一章 →