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

Question

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

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

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

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

Answer 1

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

不，这个假设是错误的。

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

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

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

我需要事件溯源来将消息写入 MQ 或使用 Kafka 吗？

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

“就地”修改模型是完全合理的，然后发布消息宣布事情发生了变化。

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

你没有。

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

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