领域驱动设计(DDD)核心概念及其在边界界定中的作用

领域驱动设计（Domain-Driven Design，DDD）为微服务边界界定提供了严谨的战术建模工具。DDD 的核心概念——实体、值对象、聚合、领域事件——不仅是领域建模的基石，更是服务边界划分的直接依据。本节将逐一解析这些概念，并阐明它们如何指导工程落地。

2.1 实体（Entity）

定义：实体是具有唯一标识且在其生命周期内状态可变的领域对象。实体的核心特征是“身份连续性”，而非属性值。两个实体即便所有属性相同，只要标识不同，就是不同的对象。

2.2 值对象（Value Object）

定义：值对象通过属性值来定义自身，没有唯一标识，且是不可变的。两个值对象只要所有属性相同，就被视为同一个对象。值对象通常用于描述实体的属性或量值。

• 不可变性：创建后不可修改，修改即创建新实例。
• 无标识：完全由属性值决定相等性。
• 自包含：行为与属性紧密耦合，如“金额”对象包含币种和数值的运算逻辑。

// 值对象示例：地址
public class Address {
    private final String province;
    private final String city;
    private final String detail;

    public Address(String province, String city, String detail) {
        this.province = province;
        this.city = city;
        this.detail = detail;
    }

    // 只有 getter，没有 setter
    // equals() 和 hashCode() 基于所有字段
}

2.3 聚合（Aggregate）

定义：聚合是一组相关对象的集合，被视为数据修改的一致性边界。聚合通过一个根实体（聚合根）对外暴露，外部只能通过聚合根访问聚合内的其他对象。聚合内部保证事务一致性，聚合之间通过最终一致性通信。

2.4 领域事件（Domain Event）

定义：领域事件是领域模型中发生的、业务人员关心的、具有业务意义的事件。它记录了“过去发生的、对业务有影响的事实”。领域事件是实现聚合间最终一致性的核心机制。

• 不可变性：事件一旦发布，不可修改。
• 命名规范：使用过去时态，如 OrderSubmitted、PaymentReceived。
• 包含数据：事件 ID、发生时间、事件类型、必要载荷（通常只包含聚合根 ID 和关键属性）。

// 领域事件示例
public class OrderSubmittedEvent {
    private final String eventId;        // 事件唯一标识
    private final String orderId;        // 聚合根 ID
    private final LocalDateTime occurredOn; // 发生时间
    private final BigDecimal totalAmount;   // 关键载荷

    // 构造函数、getter
}

2.5 核心概念在边界界定中的综合作用

下图展示了 DDD 核心概念如何层层递进，最终推导出微服务边界：

2.6 概念对比与工程决策

2.7 常见误区与避坑

• 误区一：将每个实体都拆成一个微服务。→ 纠正：实体是领域对象，微服务是部署单元。一个服务通常包含 3~5 个紧密相关的聚合。
• 误区二：值对象独立成服务。→ 纠正：值对象没有独立生命周期，应作为实体的属性存在，避免网络调用。
• 误区三：跨聚合直接调用内部方法。→ 纠正：跨聚合必须通过聚合根接口或领域事件，不能绕过聚合根直接修改内部状态。
• 误区四：领域事件过于细粒度。→ 纠正：事件应具有业务意义，避免“属性变更”级别的细粒度事件，否则会导致事件风暴和系统脆弱。