一。 事件通知
假设我们有一个具有明确定义的组件作为应用程序核心。理想情况下，这些组件是完全相互分离的，但是它们的一些功能需要在其他组件中执行一些逻辑。
最典型的情况如前所述：当组件A执行的逻辑需要触发组件B的逻辑时，A不是直接去调用B，而是触发事件将且发送到事件调度程序。组件B将侦听调度程序中的特定事件，并在事件发生时执行操作。
重要的是，这种模式的一个特征是事件携带最少的数据。它只为听众提供足够的数据，以便知道发生了什么并执行其代码，通常只是实体ID，也可能是事件创建的日期和时间。
优点
（1）弹性更大：将事件排队后，发送方组件可以继续执行其自己逻辑，即使由于错误发生，因为它们排队等候，它们可以在错误被修复时被执行。
（2）降低延迟，如果事件排队，用户不需要等待该逻辑执行;
团队可以独立发展组件，使他们的工作更轻松，更快，更容易出现问题，更灵活;
缺点
（1）如果没有使用标准，有可能变成一堆意大利面条代码。
二。 事件执行状态转移
让我们再次看看前面例子，一个具有明确定义的组件作为应用程序核心。如果A组件一些功能需要来自其他组件的数据。获得该数据的最自然的方法是询问其他组件，但这意味着被查询组件必须提供查询方法以供查询组件使用，一次两次修改增加无所谓，如果频繁要求被查询组件提供新的查询方法，说明这两个组件彼此耦合！
在组件之间共享数据的另一种方法是：拥有数据的组件触发的更改事件时，该事件将携带全新更改后的数据。对该数据感兴趣的组件将会监听这些事件，从事件中获得数据并存储该数据的本地副本，然后进一步对这些全新数据做出反应。这样，当他们需要外部数据时，他们其实在本地已经拥有它们，它们将不需要查询其他组件，也不需要其他组件提供对应的查询方法。
优点
（1）更大的弹性，查询组件不依赖被查询组件，如果被查询组件变得不可用（因为有一个错误或远程服务器是不可达到的），查询组件自身能正常工作，因为拥有了被查询组件中主数据的本地数据;
（2）减少延迟，因为没有远程呼叫（假设被查询组件是远程的）访问数据;
（3）我们不必担心被查询组件上的负载了，不用担心它是否满足来自所有其他查询组件的查询（特别是如果它是远程组件）;
缺点
（1）将有几个相同数据的副本，虽然它们是只读副本，数据存储在当下已经不是问题;
（2）更高的查询组件的复杂性，因为它将需要逻辑来维护外部数据的本地副本，尽管这是非常标准的逻辑。主从一致性。