具有事件源的 CQRS 模式具有用于读/写的单个数据库

Question

我有一个用于读取和写入操作的 SQL Server 数据库，并且我正在实现 CQRS 模式以实现代码隔离和可维护性，以便我可以将读取操作分配给团队中的少数资源，并将写入操作分配给其他资源，我认为使用 CQRS 似乎采取干净的方法。

现在，每当我的数据库中的表上发生插入/更新/删除时，我需要向需要了解我的系统中的更改的其他系统发送消息，因为我的数据库是主数据，因此这里发生的任何更改都需要投射到下游系统，以便他们获取最新数据并将其维护在自己的系统中。为此，我可以使用 MQ 或 Kafka，因此每当有变化时，我都可以生成关键消息并放入 MQ 中或使用 kafka 进行消息传递。

到目前为止，我还没有像我想象的那样使用事件源，因为我没有多个数据库用于读/写，所以我可能不需要事件源，我的假设是否正确，如果我们有单个数据库，我们就不需要事件源？或事件源可以在利用 MQ 或 Kafka 中发挥任何作用，我的意思是，如果我使用事件源模式，我可以首先将数据保存在主数据库中，然后使用事件源模式将更改写入 MQ 或使用 kafka 写入消息，我一无所知在这里，我们是否可以使用 MQ 或 Kafka 的事件源模式。

将消息写入 MQ 或使用 Kafka 是否需要事件源？或者在我的情况下根本不需要，因为我只有一个数据库，我不需要知道记录系统发生的一系列更新，我关心的是主数据库中记录的最终状态然后使用 MQ 或 Kafka 将更改发送到有 CRUD 操作的下游系统，以便下游系统获得最新的更改。

Answer 1

我的假设是否正确，如果我们有单个数据库，我们就不需要事件溯源？

不，这个假设是错误的。

在 CQRS“传统”中，事件溯源是指在持久数据结构中维护信息；当新信息到来时，我们会将这些信息附加到我们已经知道的信息中。换句话说，它描述了我们用来记忆信息的模式。参见福勒 2005 年。

当您开始谈论像 Kafka 或 Rabbit 这样的消息传递解决方案时，您会遇到不同的问题：如何在系统之间共享信息？好吧，我们将信息放入消息中，并将该消息从生产者传递给消费者。由于历史原因，该消息称为事件（参见 Hohpe 等人）。

两种不同的想法，很容易混淆。当 CQRS 人们谈论事件溯源时，他们的意思与 Kafka 人们谈论事件溯源的意思不同。

将消息写入 MQ 或使用 Kafka 是否需要事件源？

否 - 即使您选择事件溯源以外的其他记忆策略，消息传递仍然有效。

可以说，“就地”修改模型，然后发布一条消息，宣布事情已经发生变化，这是完全合理的。

当我只有一个数据库并且我不关心记录的一系列更改而只关心数据的最终状态时，为什么我需要事件溯源，

你不知道。

事件溯源的两个最常见的动机是：(a) 事件历史记录与您正在工作的领域（例如：会计）自然一致，或者 (b) 需要支持时态查询。

如果你没有这些问题，那么你就不需要它。