我想知道当我们引用SOA或中间件时，以及通常在应用程序和企业集成的情况下，消息驱动和事件驱动的环境之间是否有明显的区别。我知道用户界面类似于事件驱动模型，我们的系统拦截用户的操作。
此外，很明显消息传递支持基于发布/订阅，同步或异步通信，事务等的系统。
但是中间件/ soa /应用程序集成上下文有区别吗？ （架构级别）。我正在尝试咨询维基百科（here和here）等来源，但我仍然有些困惑。开发人员何时应该选择一种解决方案？
是否存在一种方法或案例，其中一种方法比另一种更有意义？或者是否有任何全面的资源和指南来实施每一个？
非常感谢任何见解。
对“有明显区别”的简短回答是“否”。
这些术语不是可以互换的，但暗示了相同的基本架构 - 特别是您将触发事件或消息。
您引用的第一篇文章是关于代表您传输消息的低级管道，MOM或pub-sub“总线”。事件驱动的体系结构是您在该框架之上构建的。
事件驱动这个术语虽然也适用于GUI代码，但并不是真正处于同一抽象层次。在这种情况下，与沿着消息/事件驱动的行构建整个企业相比，它是一种小型模式。
这是JonasBonér提出的问题的Typesafe / Reactive观点。从this blog post的第三段：
不同之处在于消息是定向的，事件不是 - 消息具有明确的可寻址接收者，而事件恰好发生在其他人（0-N）上以观察它。
很久以前就问过这个问题。我认为在Reactive Manifesto中Message-Driven (in contrast to Event-Driven)给出了一个更现代和更明确的反应：
消息是发送到特定目标的数据项。事件是组件在达到给定状态时发出的信号。在消息驱动的系统中，可寻址的接收者等待消息的到达并对它们作出反应，否则处于休眠状态。在事件驱动的系统中，通知侦听器附加到事件源，以便在发出事件时调用它们。这意味着事件驱动系统侧重于可寻址事件源，而消息驱动系统则侧重于可寻址收件人。消息可以包含编码事件作为其有效负载。
事件驱动的体系结构可以使用或不使用消息传递来实现消息传递是以可靠，有保证的方式将生产者提出的事件传达给消费者的一种方式。特别是当生产者和消费者真正脱钩并且可能托管在不同的服务器/ VM /环境上并且不能直接访问任何共享内存时。
但是在特定情况下 - 当事件的使用者是在同一应用程序本身内注册的函数/回调时，或者当需要同步执行消费者时，可以在没有消息传递的情况下实现事件订阅。
假设您正在为电子商务网站构建付款服务。下订单时，订单服务将要求您的付款服务授权客户的信用卡。只有在信用卡被授权后，订单服务才会将订单发送到仓库进行包装和运输。
您需要与处理订购服务的团队商定如何将信用卡授权请求从他们的服务发送到您的服务。有两种选择。
事件驱动方法的一个优点是其他服务也可以订阅各种事件。例如，可能有一个RevenueReporting服务订阅AuthorizationAccepted事件并为财务团队创建报告。
事件驱动方法的缺点是整个系统变得难以理解。例如，假设处理订单服务的团队要求您使用不同的事件替换AuthorizationDeclined事件，具体取决于信用卡被拒绝的原因（没有资金，帐户关闭，帐单地址不正确等）。如果你停止发布AuthorizationDeclined事件，那会破坏其他一些服务吗？如果您有许多活动和服务，这可能很难追查。
正如它在this文章中所说，为了理解事件驱动的设计，而不是看它呈现的内容，我们必须观察它隐藏的内容，而这只不过是编程的基础; “调用堆栈”。
在事件驱动设计中，方法调用的定义就在窗外。没有更多的来电者和被叫者。这是一个叫做序列和顺序的吻。系统不需要知道事情必须发生的顺序。因此，共享内存空间（调用堆栈的先决条件）变得不必要。
但是，在调用堆栈环境中，不仅调用者必须知道接下来会发生什么，而且必须能够将功能与方法名称相关联。
默认情况下，面向消息的应用程序会删除共享内存。发布者和订阅者不需要共享内存空间。另一方面，所有其他特征（即顺序，方法名称耦合等）不是必需品。
如果设计消息传递是为了符合事件驱动架构的公理，那么它们可以被认为是相同的。否则他们之间会有很大的不同。
如果我们使用事件驱动的方法，我们通常希望在此事件中发送源对象 - 发布事件的组件。因此，在订阅者中，我们不仅可以获取数据，还可以了解谁发布了此事件。例如。在移动开发中，我们收到View，它可以是Button，Image或一些自定义View。根据此View的类型，我们可以在订户中使用不同的逻辑。在这种情况下，我们甚至可以添加一些后处理，修改源组件 - 例如向这些源视图添加动画。
当我们使用消息驱动方法时，我们只想发布带有一些数据的消息。发布此消息的订阅者无关紧要，我们只想接收数据并进行处理。
事件驱动架构和消息驱动架构是两个不同的东西，解决了两个不同的问题。
事件驱动架构的重点是如何触发系统的功能。在EDA环境中被认为是事件的大多数触发器是通过键盘和鼠标以外的方式生成的事件。这是一个EDA，如果这让我们明确地思考事件生成器，事件通道，事件处理引擎。
键盘和鼠标是明显的事件生成器，但是这些事件的处理已经被各种框架或运行时处理，作为架构师，我们不需要担心它。特定于某些领域的其他事件是建筑师期望考虑的事情。示例 - 供应链管理事件 - 拣货，包装，发货，分销，零售商，销售等。从工业物联网应用类型的技术角度来看，事件是 - RFID读取，生物度量读取，传感器数据，条形码扫描，系统生成事件需要明确处理的事件是因为这些事件驱动系统的功能。
消息驱动架构的重点是通过使用标准的面向消息的中间件将消息从一个模块传递到系统的另一个模块来集成分布式系统。
Message概念是抽象的，更具体的消息类型是Event和Command。
虽然消息根本没有特殊意图，但事件会告知已经发生并且已经完成的事情（过去）。命令会触发应该发生的事情（将来）。