1、EDA意味着事件溯源（Event Sourcing）？
- 事件溯源是一种在服务内部持久化数据的方法。它不是将当前状态写入数据库，而是为每个状态变化存储一个事件。通过重放这些事件可以恢复状态。
- 事件驱动架构是关于服务间通信的。一个服务发布它认为对其他服务可能感兴趣的任何更改，其他服务订阅这些更新。这些事件是状态的载体，也是订阅方触发操作的信号。
2、EDA和使用Kafka是等同的？
Apache Kafka是一个基于日志的消息代理，在事件驱动系统中非常流行。它适合事件驱动架构。
但是，Kafka中发送的内容只是一个“记录”，即一个字节数组。你可以用它来发布事件、命令、查询或任何其他类型的信息，Kafka并不在乎。
你可以在不使用事件驱动的情况下使用Kafka，也可以在不使用Kafka的情况下构建事件驱动架构。例如，使用存储和转发的消息队列（如ActiveMQ或RabbitMQ）或通过实现HTTP feeds。
3、EDA只关于消息命名/语义？
使一条消息成为事件的是它描述了一个事实，即发生了某事。例如，“ShipItem”是一个命令，“OrderConfirmed”是一个事件。
如果你只关注单个消息的语义，而不考虑整体流程，可能会自欺欺人。
订单服务命令库存服务预订一件商品。它以不同的方式表达问题，即陈述，这一事实并不能使系统成为事件驱动的。对于这些看起来像事件但实际上期望特定接收者执行操作的消息，Martin Fowler 创造了“被动攻击命令”（passive-aggressive commands），这是一种看起来像事件但实际上期望特定接收者执行操作的消息。
4、EDA只有在一切都是基于事件时才有意义？
你的应用程序为前端提供REST API？那不是事件驱动的。但这并不意味着你不能在后端构建事件驱动架构。如果你的后端系统由多个服务组成，你仍然可以利用事件驱动架构来实现更好的可扩展性和弹性。
事实上，构建系统时，只有系统内部的服务间通信完全由事件驱动，而与“外部”世界的通信则使用其他模式，这种情况非常常见。这可能是用户界面，也可能是第三方系统的集成，您必须使用它们提供的任何接口，而这些接口可能不是事件驱动的。但不要让这阻止您以事件驱动的方式设计您实现的服务之间的通信。
5、EDA 本质上很复杂？
它比小型、非分布式应用程序（一个小单体应用）更复杂。但微服务也是如此。一旦你进入微服务领域，为了支持多个团队的自主开发和操作，你就需要处理分布式特性的额外挑战。
问题不应该是这个世界上是否存在比事件驱动架构更不复杂的东西（当然有）。
问题应该是：如果我构建一个微服务架构，事件驱动架构是否比基于REST或RPC调用的架构更复杂？回答是否定的。
不要将“不熟悉”误认为复杂。调用方法或函数是我们在编码时经常做的事情。发出 HTTP 请求或 gRPC 调用比发出（或消费）事件更接近于此。但仅仅因为某些东西不同并不意味着它更复杂。
如果您发出事件，则表示您已完成，并且您不想收到任何订阅者的回复。处理事件现在是他们的任务。如果做得正确，事件驱动架构可以具有美妙的简单性。
评论：
- 使用第一性原则挑战常见的定义，意识到“地图不是领土”，被动命令仍然是命令而不是事件。