聚合根不能直接声明public event，因其破坏封装性、无法控制发布时机且易致内存泄漏；应通过私有集合暂存事件，由应用服务在事务提交后统一发布并清空。
领域事件在DDD中不是靠 event 关键字直接暴露给外部订阅的——那是UI层或基础设施层的通信方式，用在聚合根里会破坏封装性、引入生命周期耦合，且无法保证事务一致性。
为什么聚合根不能直接声明 public event
聚合根的核心职责是维护业务不变量和事务边界。一旦你写 public event Action<orderplacedevent> OrderPlaced;</orderplacedevent>，外部代码就能用 order.OrderPlaced += handler 订阅，这带来三个硬伤：
- 违反聚合根“仅通过方法暴露行为”的原则：事件成了公开状态通道，而非行为结果的抽象
- 无法控制发布时机：事件可能在对象构造中途、验证失败后、或事务未提交前就被触发
- 内存泄漏风险高：UI层、仓储层、甚至测试Mock对象都可能无意中长期持有对聚合根的引用
真正符合DDD语义的做法是让聚合根“产生”事件，而不是“发布”事件。发布动作必须移交到应用服务（Application Service）或领域事件分发器（Domain Event Dispatcher）中统一处理。
聚合根内如何安全地收集领域事件
聚合根应使用私有集合暂存事件实例，典型模式是定义一个 IList<idomainevent></idomainevent> 字段，并在关键业务方法中添加事件对象（不触发、不调用）：
public class Order : AggregateRoot
{
private readonly List<idomainevent> _domainEvents = new();
public void PlaceOrder(CustomerId customerId, IReadOnlyList<orderitem> items)
{
if (items.Count == 0) throw new InvalidOperationException("Empty order");
// ... 业务逻辑校验与状态变更
_domainEvents.Add(new OrderPlacedEvent(Id, customerId, DateTimeOffset.UtcNow));
}
public IReadOnlyList<idomainevent> GetUncommittedEvents() => _domainEvents.AsReadOnly();
public void ClearEvents() => _domainEvents.Clear();
}
</idomainevent></orderitem></idomainevent>
注意三点：
-
GetUncommittedEvents()返回只读视图，防止外部修改内部事件列表 - 必须配套
ClearEvents()，否则同一聚合多次操作会重复发布旧事件 - 事件类型应实现
IDomainEvent接口（空标记接口即可），便于后续反射或泛型调度
应用服务中如何可靠发布并清空事件
事件发布必须和数据库事务绑定。典型流程是：调用聚合方法 → 获取未提交事件 → 持久化聚合状态 → 成功后再分发事件：
public async Task PlaceOrderAsync(PlaceOrderCommand cmd)
{
var order = await _orderRepository.LoadAsync(cmd.OrderId);
order.PlaceOrder(cmd.CustomerId, cmd.Items);
await _orderRepository.SaveAsync(order); // 此步提交数据库事务
// ✅ 仅在此处发布，确保事务成功才触发下游
var events = order.GetUncommittedEvents();
foreach (var e in events)
{
await _domainEventDispatcher.DispatchAsync(e);
}
order.ClearEvents(); // 防止下次 Save 重复发布
}
关键点：
- 不要在
SaveAsync前调用DispatchAsync，否则事务回滚时事件已发出，造成最终一致性断裂 - 不要依赖 EF Core 的
SaveChangesAsync后置钩子（如AfterSaveEvents），它不保证跨上下文可见性，且难以测试 - 若使用 MediatR，推荐
IPublishEndpoint.Publish()而非IMediator.Publish()，前者支持后台队列和重试策略
订阅端需注意生命周期与幂等性
领域事件订阅者（如发送邮件、更新搜索索引）通常是无状态服务，但必须明确两点：
- 它们不应持有对聚合根或仓储的长期引用——每次处理都应新建仓储实例或使用作用域服务
- 必须实现幂等：事件可能因网络重试、消费者重启等原因被重复投递，
OrderPlacedEvent的OrderId应作为唯一键写入去重表或Redis Set - 避免在事件处理器中调用
SaveChanges—— 它不属于当前事务，应走独立仓储或发消息到MQ
最易被忽略的是事件发布时间点与事务边界的对齐。哪怕代码写对了，只要把 DispatchAsync 放在 SaveAsync 前面一行，整个领域的最终一致性就失效了——这点在集成测试里很难覆盖，得靠架构约束（如静态分析插件或基类模板强制检查）。
