Answers:
这是JonasBonér对这个问题的Typesafe / Reactive观点。在此博客文章的第三段中：
区别在于消息是定向的，事件不是定向的-消息具有明确的可寻址收件人，而事件只是发生在其他人（0-N）观察它的情况下。
这个问题是很久以前问的。我认为反应式宣言在消息驱动（与事件驱动相反）中给出了更现代，更清晰的响应：
消息是发送到特定目标的数据项。事件是组件在达到给定状态时发出的信号。在消息驱动的系统中，可寻址的收件人等待消息的到达并对消息做出反应，否则将处于休眠状态。在事件驱动的系统中，通知侦听器连接到事件源，以便在发出事件时调用它们。这意味着事件驱动的系统专注于可寻址的事件源，而消息驱动的系统则专注于可寻址的收件人。消息可以包含编码事件作为其有效负载。
假设您正在为电子商务网站构建付款服务。下订单后，订单服务将要求您的付款服务授权客户的信用卡。仅当信用卡被授权后，订购服务才会将订单发送到仓库进行包装和运输。
您需要与订购服务团队合作，以了解如何将信用卡授权请求从他们的服务发送到您的服务。有两种选择。
事件驱动方法的优点是其他服务也可以订阅各种事件。例如，可能有一个RevenueReporting服务可以订阅AuthorizationAccepted事件并为Finance团队创建报告。
事件驱动方法的缺点是整个系统变得有点难以理解。例如，假设订单服务团队根据您的信用卡被拒原因（没有资金，帐户关闭，帐单地址不正确等），要求您用不同的事件替换AuthorizationDeclined事件。如果您停止发布AuthorizationDeclined事件，这会中断其他服务吗？如果您有许多事件和服务，则可能很难跟踪。
事件驱动的体系结构可以在有或没有消息传递的情况下实现。消息传递是一种以可靠，有保证的方式将生产者引发的事件传达给消费者的方法。特别是当生产者和消费者真正脱钩，并且可能托管在不同的服务器/ VM /环境中并且无法直接访问任何共享内存时。
但是，在特定情况下-当事件的使用者是在同一应用程序本身内注册的函数/回调，或者当使用者需要同步执行时，则可以在没有消息传递的情况下实现事件订阅。
消息概念是抽象的，更具体的消息类型是事件和命令。
尽管消息根本没有什么特别的意图，但事件会告知已经发生并且已经完成的事情（过去）。命令会触发某些事情（将来发生）。
由于它在很好地把这个文章，以了解事件驱动的设计，而不是在它提出我们要观察什么隐瞒，这就是没有看多非常基本的编程; “调用堆栈”。
在事件驱动的设计中，方法调用的定义直接显示在窗口之外。没有更多的主叫方和被叫方。那是一个亲吻序列和命令的吻。系统不需要知道事情必须按什么顺序发生。因此，共享存储空间（这是调用堆栈的先决条件）变得不必要。
但是，在调用堆栈环境中，不仅调用者必须知道接下来会发生什么，而且还必须能够将功能与方法名称相关联。
默认情况下，面向消息的应用程序附带删除共享内存。发布者和订阅者不需要共享存储空间。另一方面，所有其他功能（即顺序，方法名称耦合等）不是必需的。
如果将消息传递设计为符合事件驱动架构的公理，则可以将它们视为相同。否则它们之间会有巨大的差异。
事件驱动架构和消息驱动架构是两种不同的事物，解决了两个不同的问题。
事件驱动架构的重点是如何触发系统运行。在EDA上下文中被认为是事件的大多数触发器是通过键盘和鼠标以外的方式生成的事件。如果这使我们明确考虑事件生成器，事件通道，事件处理引擎，那么它就是EDA。
键盘和鼠标是明显的事件生成器，但是各种框架或运行时已经处理了这些事件，作为架构师，我们无需担心。预期架构师会考虑特定于特定领域的其他事件。示例–供应链管理事件–取货，包装，发货，分销，零售商，已售等。从工业物联网类型技术的技术角度来看，事件是– RFID读取，生物识别读取，传感器数据，条形码扫描，系统生成的事件是需要明确处理的事件，因为这些事件驱动系统的功能。
消息驱动体系结构的重点是通过使用标准的面向消息的中间件将消息从一个模块传递到系统的另一个模块来集成分布式系统。
在OO中，它通过呼叫者和被叫者之间的消息方式进行交互。在GUI中，我们总是说事件驱动。我们可以看到，如果需要同时管理发布者和订阅者之间的关系，则应该使用事件驱动。如果我们在没有强依赖性的情况下管理更抽象的上游和下游基础（例如上游不知道下游），则应使用消息驱动。因此，在Message-Middleware上下文中，没有明显的区别，而是结构差异而不是设计差异。