message-queue - CQRS/上下文之间的通信/事件存储/推送或拉取？

Question

CQRS/ES架构中限界上下文之间的通信是通过事件来实现的；上下文 A 生成事件作为对命令的响应，然后这些事件通过事件总线(消息队列)转发到上下文 B。

或者...您可以将事件存储在事件存储中(属于上下文 A)。
或者...两者(存储和转发)。

我的问题是:从上下文 B 中，我应该从上下文存储中提取事件吗？或者只是消耗通过事件总线推送的事件？

我倾向于拉动方法。因为这样我们就可以在上下文 B 中进行一些追赶。相比之下，在推送方法中，上下文 B 可能不知道在 B 经历停机时传递的事件。

那么......这是否意味着......当我们拥有事件存储时，我们可以简单地忘记消息队列(似乎是多余的)？

或者我在这里错过了什么？

Answer 1

您需要查看 Consume event stream without Pub/Sub

At the DDD Europe conference, I realized that the speakers I talked with where (sic) avoiding Pub/Sub whenever possible.

下面的讨论可能有值(value)。 TL;DR:那里的 pub/sub 粉丝并不多。
康拉德·加鲁斯 (Konrad Garus) 上 Push or Pull? ，描述拉式设计:

In the latter (and simpler) design, they only spread the information that a new event has been saved, along with its sequential ID (so that all projections can estimate how much behind they are). When awakened, the executor can continue along its normal path, starting with querying the event store.

Why? Because handling events coming from a single source is easier, but more importantly because a DB-backed event store trivially guarantees ordering and has no issues with lost or duplicate messages. Querying the database is very fast, given that we’re reading a single table sequentially by primary key, and most of the time the data is in RAM cache anyway. The bottleneck is in the projection thread updating its read model database.

总的来说，归结为:当人们考虑事件溯源时，他们实际上是在考虑历史，而不是孤立的事件。如果您真正想要的是一个没有间隙的有序事件序列，那么查询该序列的权限要比尝试从一堆不相交的事件消息中重建 if 好得多。
但是——一旦你决定这样做，突然间，历史和其中出现的所有事件都成为上下文 A 的 api 的一部分。当团队 A 决定不同的事件存储实现更合适时会发生什么？他们可以推出自己的服务的新版本，还是我们需要大停电，因为每个消费者也必须得到更新？
同样，如果我们决定将上下文 A 重构为上下文 C 和上下文 D，会发生什么？同样，我们是否必须在上下文 B 中搞砸才能获得我们需要的数据？
也许真正的问题是上下文 B 与上下文 A 中的历史耦合，而这些历史真的应该是私有(private)的吗？上下文 B 应该访问上下文 A 的数据，还是应该将这项工作委托(delegate)给上下文 A 的功能？
乌迪·达汉 essays on SOA可能会开始朝那个方向思考。