3. 事件溯源核心原理：以事件为唯一真相源、事件存储、事件流与聚合重建

事件溯源（Event Sourcing, ES）颠覆了传统以“当前状态”为中心的持久化范式。在 ES 中，事件是唯一的真相源（Source of Truth），系统的当前状态仅是通过重放事件流计算得出的副产品。本节将深入剖析 ES 的三大核心支柱：事件作为唯一真相源、事件存储与事件流、以及聚合重建机制。

3.1 以事件为唯一真相源

传统 CRUD 系统直接存储聚合的当前快照，丢失了所有变更的历史上下文。事件溯源则记录每一个已发生的事实，这些事实是不可变、可追加的。

3.2 事件存储：不可变日志的物理实现

事件存储（Event Store）是 ES 的持久化基础设施，它本质上是一个仅追加的日志。每个事件都包含以下关键字段：

• EventId：全局唯一标识（UUID）。
• AggregateId：所属聚合的标识。
• AggregateType：聚合类型（如 Order）。
• EventType：事件类型（如 OrderPlaced）。
• Data：事件载荷（JSON 或二进制序列化）。
• Metadata：元数据（时间戳、用户ID、关联ID等）。
• Version：聚合内的版本号（单调递增）。

-- 事件存储表结构示例（PostgreSQL）
CREATE TABLE events (
    event_id        UUID PRIMARY KEY,
    aggregate_id    UUID NOT NULL,
    aggregate_type  VARCHAR(100) NOT NULL,
    event_type      VARCHAR(100) NOT NULL,
    data            JSONB NOT NULL,
    metadata        JSONB,
    version         INTEGER NOT NULL,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE (aggregate_id, version)
);

CREATE INDEX idx_events_aggregate
    ON events (aggregate_type, aggregate_id, version);

3.3 事件流：聚合的生命线

事件流（Event Stream）是按时间顺序排列的、属于同一个聚合实例的所有事件的序列。每个聚合实例对应一个独立的事件流。

下图展示了一个订单聚合的事件流生命周期：

3.4 聚合重建：从事件流到当前状态

聚合重建（Aggregate Reconstruction）是 ES 的核心操作：通过重放聚合的完整事件流，依次调用每个事件的 apply 方法，逐步构建出聚合的当前状态。

3.4.1 重建流程

1. 加载事件流：从事件存储中读取指定聚合 ID 的所有事件，按版本升序排列。
2. 创建空聚合：实例化聚合对象，初始状态为默认值（如空集合、零值）。
3. 重放事件：遍历事件流，对每个事件调用聚合的 apply(event) 方法，该方法内部更新聚合状态。
4. 返回就绪聚合：重放完成后，聚合处于最新状态，可接受新的命令。

// 聚合重建核心逻辑（TypeScript 伪代码）
class OrderAggregate {
  private state: OrderState = { items: [], status: 'pending', total: 0 };

  // 重放事件流
  static loadFromHistory(events: DomainEvent[]): OrderAggregate {
    const aggregate = new OrderAggregate();
    for (const event of events) {
      aggregate.apply(event);
    }
    return aggregate;
  }

  // 应用单个事件
  private apply(event: DomainEvent): void {
    switch (event.type) {
      case 'OrderPlaced':
        this.state.items = event.data.items;
        this.state.status = 'placed';
        break;
      case 'PaymentReceived':
        this.state.status = 'paid';
        break;
      case 'OrderShipped':
        this.state.status = 'shipped';
        break;
      // ... 其他事件处理
    }
  }

  // 当前状态只读访问
  getState(): Readonly<OrderState> {
    return this.state;
  }
}

3.4.2 快照优化

当事件流非常长（数万甚至数百万个事件）时，每次重建都从头重放会导致性能问题。解决方案是引入快照（Snapshot）：

• 定期（如每 100 个事件）保存聚合状态的快照。
• 重建时，先加载最近的快照，然后仅重放快照之后的事件。

3.5 事件溯源架构总览

下图展示了事件溯源在典型后端发布拓扑中的完整数据流：

3.6 关键设计考量

• 事件版本兼容性：事件结构会随时间演化。需设计事件版本策略（如 EventUpcaster），确保旧版本事件能被当前聚合代码正确重放。
• 并发控制：使用乐观锁（基于聚合版本号）防止并发命令导致的事件流冲突。
• 事件幂等性：事件存储应保证同一事件不会被重复追加。通常通过 event_id 唯一约束实现。
• 性能与存储：事件存储是写优化的，读（重建）可通过快照和缓存优化。长期运行的系统需考虑事件归档策略。