Jacqui Read：软件架构中的事件指南

我想厘清软件中“事件”的许多用法：命令、流、事件驱动架构、EventStorming、事件溯源以及几类不同事件。名称相似并不意味着这些概念可以互换。

事件表示已经发生的事情。发生时间很重要；事件记录事实，而不是要求另一个组件执行动作。现有软件使用事件对象已有几十年，图形界面就是例子之一。

事件可以携带变更信息，例如偏好设置发生变化。事件包含什么会影响消费者：如果消费者依赖生产者的内部表示，该表示发生变化就可能产生耦合。

命令要求已知接收方做某件事，并期待其采取行动。事件发布已经发生的事实；发布者不一定知道谁会作出反应。消息是更宽泛的类别，可以包含两者。

例如，创建、开始和完成工作项可以用命令及相应的过去式事件表达。区分请求与事实，有助于判断实际发生了什么。

监听器和处理器的术语用法并不完全一致。监听器等待某类事件并触发回调代码；有些人把回调称为处理器，另一些人则用这个词指整个机制。

事件流处理持续的数据流，可以支持近实时处理，而不必等待批处理。服务或设备等生产者发布事件；消费者订阅自己需要的信息。

消息日志按偏移量保存条目。消费者跟踪自己的进度，以便故障后恢复。消费者可能重放已经处理过的记录，因此处理设计要考虑幂等性；新消费者也可以选择特定起始窗口。

示例中的队列具有不同语义：一个或多个竞争消费者取走消息，确认处理后该消息不再出现在队列中。如果处理没有得到确认，消息可以重新变为可供其他消费者处理。

在命令驱动的网络中，服务可能直接知道并调用彼此。事件驱动架构则可以通过 broker 发布和订阅，减少部分直接依赖。Broker 本身仍需按所需可靠性和吞吐量设计。

这种间接性也有代价：只展示服务和 broker 的图可能隐藏最终由谁消费数据。在分布式系统中，追踪下游依赖并预测变更影响可能很困难。

EventStorming 让业务和技术参与者一起绘制事件、参与者、系统、机会和问题点。目的是挖掘不同人掌握的知识，并理解接下来发生什么，而不是假定一切都有文档。

关键事件可以揭示限界上下文之间的转换。团队可能在这些边界上争论术语，因为同一信息在不同领域模型中有不同含义；识别边界有助于明确转换。

全景 EventStorming 是多人参与的广泛探索。流程建模把范围缩小到设计或重新设计工作流；软件设计会议则进一步聚焦技术和用户体验决策。

事件溯源把变更保存为事件，而不是只保存最新状态。重放这些变更可以重建过去的状态，就像版本历史可以帮助查看旧版本。传统状态存储可能需要单独的日志或备份才能恢复同样的历史。

她介绍了为实体或聚合使用事件流，并在有用的业务边界拆分长期事件流。合适的边界取决于写入量和领域需求；缓存或投影可以加快读取当前状态。

事件存储可以是专用数据库，也可以是配合支持软件使用的通用数据库。事件表示过去的事实，通常不会原位修改。讲者提到加密和删除密钥是一种可能的隐私技术；它是否满足具体法律义务取决于实现和适用要求。

Tombstone 通常表示数据不再存在，但确切含义取决于系统。她比较了标记事件流删除、填补序列缺口以及在重试模式中表示完成等用法；同一个词用于不同目的。

在重试示例中，暂时无法处理的事件被转移，后续相关事件也被保留等待重试，以免超过它。完成标记帮助主流程知道被转移的工作何时结束。

领域事件描述领域或限界上下文内有意义的发生事项；集成事件跨边界传递信息。讲者呼吁团队像设计 API 一样认真设计事件，并考虑生产者与消费者共享的模型。

事件粒度需要权衡。小型通知可能要求消费者回调生产者获取更多数据，从而增加耦合和延迟；过大的事件则可能传播无关信息并产生其他依赖。

她建议事件尽可能小，但又足够大，使消费者不必立即回调生产者就能采取行动。合适的大小取决于工作流及其消费者，而不是统一的载荷模板。

演讲以回顾术语和介绍进一步学习资源收尾。理解这些区别有助于团队选择合适的模式，而不是假设所有与事件有关的技术都解决同一个问题。