关于如何触发投影的问题

Question

我正在学习 CQRS 和常见的战术 DDD 模式，但我对如何触发另一个微服务中的预测有点困惑。

出于学习目的，我现在没有使用事件源，读取的模型存储在 PostgreSQL 数据库中。

说到问题，当执行命令时，聚合会被更新并存储到 PostgreSQL 数据库中。我的问题是如何让不同微服务上的投影知道何时触发投影并更新读取模型？

我有几个关于传播什么、以什么形式、通过什么渠道传播的问题：

1. 关于传播什么 - 我假设用于持久性的事件溯源事件与用于松散耦合的领域事件和集成事件不同。因此，人们通常会将他们保存的细粒度事件源事件发送到事件存储（例如 ProductNameChangedEvent 或 ProductShipmentReceivedEvent）以更新预测。由于我没有使用事件溯源，我是否应该发送我保留的模型，并使用它来触发投影，例如 ProductUpdatedEvent？或者我也应该发送粒度事件？
2. 关于传播的形式和渠道 - 我应该以 IntegrationEvents 的形式发送这些事件吗？我问这个问题是因为我对 IntegrationEvents 是否应该仅用于其他服务的基于业务的事件而不是仅用于更新数据库的事件感到困惑。 抱歉，如果我在某些方面听起来很愚蠢，如果我在问题之外的概念上也犯了错误，请告诉我。

Answer 1

我问这个是因为我很困惑

1. 这不是你的错。
2. 文学很烂。

---

执行命令时，聚合会更新并存储到 PostgreSQL 数据库中。我的问题是如何让不同微服务上的投影知道何时触发投影并更新读取模型？

常见的答案是设计您的协议，以便消费者轮询提供商以了解更改/更新。毕竟，如果在提供商宣布更新时消费者因维护而停机，您无论如何都必须回退到这一点。

您的轮询间隔取决于客户满足其自身服务水平目标的能力（当拥有新鲜信息至关重要时频繁轮询，而当陈旧信息的成本较低时则不那么重要）。

对于需要共享一些异常紧急的更改的情况，提供商会向消费者推送通知 - 本质上是一条消息，表示“您应该尽快进行轮询”。

我假设用于持久性的事件溯源事件与用于松散耦合的领域事件和集成事件不同。

是的，但不要太纠结于语义。信息通过消息从这里移动到那里。如果要正确理解信息，生产者和消费者需要对消息的语义有共同的理解，并且您需要谨慎设计消息，以便可以改进它们以满足未来的需求。

当协调生产者和消费者之间的更改是昂贵时，那么您需要投资设计消息模式，以便对模式的更改不需要协调更改（也称为向前/向后兼容性）。

Kicker：你持久的信息表示“只是”从过去的你到未来的你的消息。它们的特别之处在于，当生产者和消费者是同一事物时，生产者和消费者之间的协调变化成本很低。