1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

领域事件：领域中"已经发生、业务关心"的事。

  特征：
    - 过去式命名（OrderPlaced、PaymentReceived、ItemShipped）
      → "已下单""已付款""已发货"，是事实，不是请求
    - 不可变（发生过的事不能改）
    - 自描述（带够重建上下文所需的信息）

  价值：解耦
    聚合 A 完成变更 → 发事件
    聚合 B/C/D 各自订阅，独立响应
    A 不需要知道有谁在听、有几个、在哪

1
2
3
4
5
6
7

为什么用"过去式"：
  OrderPlaced（订单已创建）—— 事实，谁都不能撤销
  PlaceOrder（去下单）—— 这是"命令"，不是事件

  事件 = 已经发生的客观事实 → 订阅者只能反应，不能拒绝
  命令 = 要求做某事 → 可以被拒绝（余额不足、库存不够）
  两者别混（下一节细讲）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

命令（Command）：表达"意图"，可被拒绝
  名字：动词原形 / 祈使（PlaceOrder、CancelOrder）
  方向：外部 → 领域
  结果：可能成功，可能失败（业务规则不允许）
  例：用户点"下单" → 发 PlaceOrder 命令 → 系统校验，成功则订单创建

事件（Event）：表达"事实"，不可拒绝
  名字：过去式（OrderPlaced、OrderCancelled）
  方向：领域 → 外部
  结果：已成事实，订阅者只能据此反应
  例：订单创建后 → 发 OrderPlaced → 库存扣减、积分、通知据此触发

  链条：
    命令 PlaceOrder →（校验通过）→ 订单创建 + 事件 OrderPlaced
    → 订阅者据此发新命令（如 ReserveStock）→ 成功 + StockReserved
    → ... 一个业务的完整流程 = 命令与事件交替推进

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 领域事件基类
public interface IDomainEvent
{
    DateTime OccurredOn { get; }
}

// 具体事件：过去式 + 自描述（带够订阅者需要的信息）
public sealed record OrderPlaced(
    OrderId OrderId,
    CustomerId CustomerId,
    IReadOnlyCollection<OrderLine> Lines,
    Address ShippingAddress,
    Money Total,
    DateTime OccurredOn
) : IDomainEvent;

public sealed record OrderCancelled(OrderId OrderId, string Reason, DateTime OccurredOn)
    : IDomainEvent;

// 聚合根内：变更完成后"收集"事件，由外部统一分发
public class Order : Entity<OrderId>, IAggregateRoot
{
    private readonly List<IDomainEvent> _events = new();
    public IReadOnlyCollection<IDomainEvent> DequeueEvents()
    { var e = _events.ToList(); _events.Clear(); return e; }

    public void Cancel(string reason)
    {
        if (Status >= OrderStatus.Shipped)
            throw new DomainException("已发货不能取消");
        Status = OrderStatus.Cancelled;
        _events.Add(new OrderCancelled(Id, reason, DateTime.UtcNow));  // 只收集，不直接处理
    }
}

1
2
3
4
5
6

设计要点：
  1. 事件是 record（不可变）+ 过去式命名
  2. 带够信息：订阅者不该为了处理事件再去回查聚合
     （但也不必塞全部字段，按订阅者需要）
  3. 聚合只"收集"事件，不直接处理（保持聚合纯净、可测）
  4. 事件的分发由应用层统一做（下一节）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// 应用层：保存聚合后，把收集到的事件分发出去
public class OrderService
{
    private readonly IOrderRepository _repo;
    private readonly IDomainEventDispatcher _dispatcher;

    public async Task CancelAsync(OrderId id, string reason, CancellationToken ct)
    {
        var order = await _repo.Find(id, ct) ?? throw new NotFoundException();
        order.Cancel(reason);                 // 聚合内变更 + 收集事件
        await _repo.Save(order, ct);          // 先持久化（保证数据落库）

        foreach (var evt in order.DequeueEvents())
            await _dispatcher.DispatchAsync(evt, ct);  // 再分发
    }
}

// 分发器：可以用 MediatR（进程内发布/订阅的标准选择）
public sealed record OrderCancelledHandler(IInventoryService Inventory)
    : INotificationHandler<OrderCancelledNotification>
{
    public Task Handle(OrderCancelledNotification n, CancellationToken ct)
        => Inventory.ReleaseAsync(n.OrderId, ct);  // 库存释放
}

1
2
3
4
5

关键顺序：先存库，再分发
  如果先分发再存库：事件处理了，但聚合没存上 → 不一致
  所以一定 先 Save 聚合 → 再 Dispatch 事件

  进程内的同步分发，简单可靠，但有个隐患（下一节）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

进程内分发的隐患：
  聚合存了 ✅ → 分发事件时崩了 ❌
  → 库存没释放、积分没加，事件丢了

  跨服务（微服务）更严重：事件要发到消息队列，队列和网络都可能失败。

  解决方案：Outbox 模式（微服务系列第五篇讲过）
    1. 聚合变更 + 事件记录，写进同一个数据库事务（原子）
    2. 一个独立 worker 轮询 outbox 表，把事件投递到消息队列
    3. 投递成功标记已发送；失败重试

  → 业务操作和事件发布，获得 ACID 级别的原子性。
  → 跨服务的领域事件，必须走 Outbox，否则一定会丢。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

传统持久化：存"当前状态"
  订单表：status=Shipped, total=299
  → 只知道"现在是什么"，历史丢了（怎么变到这一步的？不知道）

事件溯源：存"导致状态变化的所有事件"
  事件流：
    OrderPlaced(total=299)
    PaymentReceived(amount=299)
    OrderShipped(carrier=SF)
  → "当前状态" = 把事件流从头"重放"计算出来

  订单的当前状态，就是按顺序应用这些事件得到的结果。
  完整历史永久保留：能回溯到任意时间点、能审计、能做时态查询。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

事件溯源的好处：
  ✓ 完整审计轨迹（发生了什么，一清二楚）
  ✓ 时态查询（"上周三这个订单是什么状态？"）
  ✓ 和 DDD 天然契合（领域事件本就是"发生的事"）
  ✓ 模型与存储解耦（存事件，状态是派生的）

事件溯源的代价：
  ✗ 复杂度飙升（重放、快照、版本演进、并发）
  ✗ 查询难（要查"当前所有已发货订单"得重放全部 → 需要读侧投影，第五篇 CQRS）
  ✗ 事件 schema 演进困难（老事件怎么重放？）

  结论：大多数业务不需要事件溯源。
       只在"强审计/合规/时态"需求（金融、计费、医疗）才值得上。
       别因为"看起来高级"就用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// 事件流持久化（伪代码）
public interface IEventStore
{
    Task AppendAsync(OrderId id, IEnumerable<IDomainEvent> events, int expectedVersion, CancellationToken ct);
    Task<IReadOnlyList<IDomainEvent>> LoadAsync(OrderId id, CancellationToken ct);
}

// 重建聚合：重放事件流
public class OrderRepository
{
    private readonly IEventStore _store;
    public async Task<Order?> Find(OrderId id, CancellationToken ct)
    {
        var events = await _store.LoadAsync(id, ct);
        if (events.Count == 0) return null;
        var order = new Order();                       // 空聚合
        foreach (var e in events) order.Apply(e);      // 逐个重放
        return order;
    }
}

// 聚合内的 Apply：根据事件设置状态（不校验，因为是已发生的事实）
public class Order
{
    public void Apply(IDomainEvent e)
    {
        switch (e)
        {
            case OrderPlaced p: Id = p.OrderId; Status = OrderStatus.Placed; Total = p.Total; break;
            case PaymentReceived: Status = OrderStatus.Paid; break;
            case OrderShipped: Status = OrderStatus.Shipped; break;
            case OrderCancelled: Status = OrderStatus.Cancelled; break;
        }
    }
}

1
2
3
4

快照（Snapshot）：重放太慢的优化
  每 N 个事件存一个"状态快照"
  重建时：从最近快照开始 + 重放之后的少量事件
  → 长事件流的聚合才需要，先别过度设计。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

领域事件：强烈推荐，几乎必用
  ✓ 跨聚合解耦（聚合不直接调聚合）
  ✓ 副作用隔离（通知、积分、统计 = 订阅者，不污染核心）
  ✓ 跨服务异步协作（配 Outbox）

事件溯源：谨慎，按需
  ✓ 金融/计费/医疗等强审计场景
  ✗ 普通 CRUD 业务（用状态持久化就够）
  ✗ 团队没准备好应对复杂度

  事件 ≠ 事件溯源。
  用领域事件解耦，是基本操作；
  用事件溯源存状态，是高级选项，别混为一谈。