事件驱动架构最常被当成什么用？
简单说，当成一次性能升级。上消息队列，拆出事件日志，让服务之间别互相干等，听起来就是"更快"。
七月初 dev.to 上有篇把这层说法反过来讲的文章，作者 Ali Alp。他的主张一句话：事件驱动的核心收益是解耦，速度不是。每多一个 broker、一层事件日志、一次网络跳、一道序列化边界，复杂度和延迟都是往上加的。
这条我抄下来了。下面几张卡顺着它来。
试金石：一个事实要不要被几个互不相干的业务域同时消费
作者给的判断标准很干脆。一笔订单生成出来，发货、计费、库存、风控各要按自己的节奏对它作出反应，这时事件驱动才值得上。它能松开紧耦合，也能免掉一个总编排的瓶颈。
反过来也成立。如果只是 A 服务调 B 服务，同步接口或者一个轻量点对点队列就够了。等硬约束逼你改，再改。
文章点名：第一天就架重量级 broker 是过度工程
架构模式应该被硬约束推着长出来，不是照大厂博客的方案抄一份贴到自己项目上。
这条对小团队比对大厂更有用。大厂那套是从他们的约束里长出来的，你的约束不是那些。
评论区补的那一句，比原文的试金石更实用
一个叫 arun rajkumar 的读者说，同步调用失败，堆栈给你一个行号。事件丢了，你得在生产者到好几个消费者之间找它到底断在哪一环。
他追问作者：有没有信号能判断一个团队已经准备好运维这套东西，比如第一个订单事件扩散出去之前，追踪和死信队列有没有就位。
试金石判断的是业务要不要，这个问题判断的是你扛不扛得住。后者更容易被跳过。
文章还引了康威定律，这段是全文我最想让人看到的
软件架构是社会技术系统。组织如果是刚性自上而下，跨团队决策要集中同步、要拿全局锁，技术架构迟早腐化。
作者列了两个前置条件：团队有没有微领域自治的能力，工程师能不能从盯着同步数据库状态，切换到异步流、重试、乱序事件这套思维。
这段把"解耦"从代码里拎出来了。你可以在代码库里引入 broker，但你没法用 broker 引入自治。买不来。
AI agent 和事件驱动是天然搭档
文章末尾的这段。现代 AI 编排本身就是并行的，多个 agent 在后台跑任务、等别的 agent 送输入、响应上下文变化，事件驱动骨干适合非阻塞地协调它们。
这条我认同一半。agent 确实天然是异步分布的，配异步骨干是顺的。但反过来不成立：不是因为你上了 agent，就有理由上事件驱动。上面那两条门槛，一条都不少。
作者在回复里给过一个例子。用户下单，发货服务挂了，计费照样能开票，发货恢复之后用户收到通知。好处是实打实的，代价也是实打实的。调试、追踪、基础设施三样都更贵。两个域能独立发布，是真的。出问题之后要在好几个消费者之间定位它断在哪，也是真的。
那篇里还有硬实时、软实时的分类，医疗仪器、雷达跟踪、高频交易算硬实时。这段我这次不碰，讲下去就把话题带到延迟预算那边了，跟我想说的这条线没关系。
作者和一位读者来回了好几轮，值得看的不是结论
评论区里 Alex Shev 讲得比原文更准。他说速度框架害了很多事件驱动的设计，减少局部耦合的同时会生出新的协调面：事件契约、重放行为、故障归谁、跨域怎么调。这些没人主动管，速度收益就只停在纸面上。
作者的回应我也认。他说收益应该写进设计会和架构文档，写成一句句能验证的话，而不是一句"解耦了"。
这大概是整条讨论里最实用的一条。架构文档里写"提升解耦"，评审会上没人能反驳，也没人能验证。写"发货挂了计费照开票"，就可以。
这篇我其实只吃透了七成，评论区那几轮的细节比我复述得密。先放在这里，等我哪天真拿它去改一个系统，再回来补一段。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。