一、事件驱动就像外卖订单，不是越多越好
想象你开了一家餐厅，每接一个订单就发一条短信给厨师、配菜员和送餐员。刚开始生意不错，但随着订单暴增，整个后厨乱成一锅粥——厨师同时收到20个订单提醒，配菜员找不到对应的食材，送餐员跑错桌号。这就是过度使用事件的典型场景。
在领域驱动设计(DDD)中，事件(event)原本是用于解耦领域模型的利器，比如用OrderPlacedEvent触发后续流程。但很多开发者容易陷入"事件狂热症"：
// 错误示例：滥用事件的C#代码（.NET Core技术栈）
public class OrderService
{
// 一个下单动作触发5个事件！
public void PlaceOrder(Order order)
{
_eventBus.Publish(new OrderValidatedEvent(order));
_eventBus.Publish(new InventoryCheckedEvent(order));
_eventBus.Publish(new PaymentProcessedEvent(order));
_eventBus.Publish(new LogisticsNotifiedEvent(order));
_eventBus.Publish(new AnalyticsRecordedEvent(order));
}
}
// 问题：这些本该是事务内的步骤，却被拆分成独立事件
就像餐厅运营需要区分"核心流程"和"附加服务"，领域事件也应该有明确边界。我曾见过一个电商系统，用户点击购买后竟触发了12个事件，导致调试时像在玩"事件连连看"。
二、事件风暴变事件灾难的三大征兆
1. 像蜘蛛网一样的事件流
当你的架构图开始像蜘蛛捕食的网，事件处理器之间形成循环依赖：
// 危险的事件循环（.NET Core + RabbitMQ）
public class AHandler : IEventHandler<BEvent> {
public void Handle(BEvent e) => _bus.Publish(new AEvent());
}
public class BHandler : IEventHandler<AEvent> {
public void Handle(AEvent e) => _bus.Publish(new BEvent());
}
// 注释：A等B，B等A，就像两个对着喊话的人
2. 事件版本地狱
由于事件过度细化，每次业务变更都要处理事件兼容性问题：
// 版本混乱的订单事件（使用Newtonsoft.Json序列化）
[Obsolete("请使用OrderV2Event")]
public class OrderEvent {
public string OrderId { get; set; }
// 缺少关键字段
}
public class OrderV2Event {
public Guid OrderId { get; set; }
public string Currency { get; set; }
}
// 注释：就像餐厅换了菜单但没通知所有服务员
3. 调试时需要"福尔摩斯式推理"
当某个订单状态异常时，开发者不得不像侦探一样追踪十几个事件日志。我曾遇到一个BUG，最终发现是因为InventoryUpdatedEvent比PaymentCompletedEvent晚到了0.5秒。
三、如何给事件驱动设计"减肥"
原则1：区分命令与事件
就像餐厅里"做鱼香肉丝"是命令，"肉丝用完了"才是事件：
// 健康的事件使用示例（.NET Core）
public class OrderCommandHandler {
public async Task Handle(PlaceOrderCommand cmd) {
// 事务性操作
var order = _repo.Create(cmd);
await _payment.Charge(order);
_repo.UpdateInventory(order);
// 成功后发布单个聚合事件
_bus.Publish(new OrderCompletedEvent(order.Id));
}
}
// 注释：核心流程保持事务，后续操作通过单个事件触发
原则2：事件要粗粒度
好的事件像报纸头条，差的像碎碎念的日记：
// 推荐做法：聚合相关变更
public class OrderFulfillmentEvent {
public Guid OrderId { get; }
public Address ShippingAddress { get; }
public List<Item> UpdatedItems { get; }
// 代替原来的3个细粒度事件
}
原则3：设置事件边界上下文
给事件加上业务语义标签，就像餐厅分热菜区和冷菜区：
// 使用Metadata明确事件边界
public class OrderEvent {
[Context("Inventory")]
public bool AffectsInventory { get; set; }
[Context("Analytics")]
public bool IsTrackingEvent { get; set; }
}
// 注释：通过属性标记让订阅方快速判断处理逻辑
四、实战中的平衡艺术
在物流系统中，我们曾重构过订单状态模块。原始版本有OrderCreated、OrderPaid、OrderShipped等8个事件，重构后合并为OrderStatusChangedEvent，并通过状态机模式处理：
// 状态机处理示例（.NET Core + Stateless）
public class OrderStateMachine {
private StateMachine<Status, Trigger> _sm;
public void Configure() {
_sm.Configure(Status.Paid)
.Permit(Trigger.Ship, Status.Shipped)
.OnEntry(() => _bus.Publish(
new OrderStatusChangedEvent(Status.Shipped)));
}
}
// 注释：用状态机代替分散的事件更符合业务本质
监控方面，建议为事件系统添加以下指标：
- 事件处理延迟百分位值
- 死信队列增长率
- 事件溯源回放成功率
五、什么时候该用事件驱动
适合场景：
- 需要最终一致性的跨微服务协作（如库存与订单）
- 异步通知第三方系统（如短信、ERP）
- 时间解耦的批处理任务（如夜间报表生成）
不适合场景：
- 强事务要求的核心业务（如支付验证）
- 高频的实时状态同步（如游戏帧同步）
- 简单的CRUD操作（直接调用服务更清晰）
记住：事件驱动不是银弹。就像优秀的餐厅经理知道，有些订单需要全程跟踪，有些则只需在完成后通知一声。关键在于理解业务的真实节奏，而不是为了"先进架构"的虚名把简单问题复杂化。
评论