我们都希望有用和有趣的内容被推送给我们。新闻提醒出现在我们的手机上，信息通知出现在我们的桌面上。我们希望了解最新的事件，而不是去寻找它们。当相关的信息被传递给我们时，这就容易多了。
事件驱动的系统也是如此。当信息出现在需要的地方，而不是一个系统不得不先调用另一个系统时，效率会高很多。通过订阅一项服务，事件驱动系统知道它们的最新情况，并拥有准确的信息。这只是事件驱动系统的一个优势。
为了知道何时使用事件驱动架构，我们必须了解有哪些替代方案，它们的好处和缺点，以及何时最合适。
事件驱动和面向服务架构（SOA）之间的区别是什么？
面向服务的架构(SOA)
从历史上看，SOA是对旧的孤立的软件基础设施的回应，即企业内的每个领域都有自己的软件，专门用于自己的目的，与任何其他系统没有联系，只为一个目的服务。SOA允许独立的元素在整个企业中共享信息。以SOA作为系统的架构，服务是最重要的方面。
要记住的SOA的一个重要方面是，它是一个企业范围内的概念：软件基础设施的每一部分都需要被连接起来，由一种语言统一。Michael Lebow在担任IBM网络服务副总裁时说，SOA "建立了高速公路"。这很好地说明了SOA是什么：一个连接不同服务的网络，而且每个服务的连接可以很容易地复制到整个系统的不同服务中。
SOA定义了一个系统的不同组件如何一起工作。一个以SOA构建的系统有一个定义语言或协议，将系统的每一部分联合起来：这些可以是HTTP、JSON或其他网络语言。系统中的每个服务都可以用共同的语言与其他服务进行交流，各个服务可以通过共享的语言被监控或共同工作。这有助于统一孤立的语言而不影响其性能。
它通常用于那些在一段时间内没有机会重新思考其架构的老公司。SOA不是一种允许可持续发展的架构风格，因为它随着业务的发展而引入了复杂性。
事件驱动架构（EDA）
事件驱动架构将系统中发生的一切视为事件，是对企业架构的一次彻底的重新思考。将事件作为你的系统的基础，使开发者能够在软件架构中创建一个所有其他系统都可以依赖的单一真理源。一个在基本层面上由事件生产者和事件消费者组成的系统，每一个都是由单一真理源提供信息，使其用户能够做出更好的商业决策并充分了解所有相关信息。它还使不同的服务能够独立工作：一个事件生产者可以为不同的目的和结果通知两个消费者，而且你可以依赖这两个消费者的正确性。
通过事件驱动架构，事件本身才是你的系统中最重要的方面，而不是该系统中的服务。它把你的事件（下的订单、测量的读数、收到的反馈等）作为优先事项，特别是记录这些事件所发生的情况。尽管SOA能确保系统的消息被传递，但它不能记录它们。EDA不仅可以传递系统的信息，还可以对信息进行优先排序并提供背景。
与SOA不同，EDA不一定会随着业务的发展而增加复杂性。通过建立一个以事件为基础的业务架构，复杂性更容易管理：生产者和消费者可以被添加到业务事件流中，并以有效的方式移除。在SOA中，当添加到数据库时，第一个问题是 "我如何让定义语言解释这个新添加的内容？"。有了EDA，"如何 "不是问题，"哪里 "和 "什么是最有效的 "可能是第一个问题，为开发团队消除了一层复杂的因素。
应该使用哪个？
使用SOA或事件驱动的架构将取决于你的业务需求。SOA对于那些没有能力重新思考他们的架构或他们想从他们的数据中得到什么的公司来说是非常好的。如果你的企业中存在着需要整合的孤岛式应用，那么你可能不得不使用SOA作为迈向更统一的现代架构的一步。
事件驱动的架构对于那些希望保留所有事件及其历史记录的企业是最有效的。许多行业的成功企业都将事件作为其系统架构的基础。使用事件作为架构的驱动力，使你的企业能够在广泛的服务中访问大量的数据，并以一种紧凑的方式存储它们。试想一下，通过分析你的企业中曾经发生过的所有事件，你可以获得什么样的洞察力......
你的架构的最终目标是什么，是为你现有的基础设施服务并管理不同应用程序之间的通信，还是创建一个新的基础设施，将业务事件放在首位并最大限度地利用你的数据？