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

Question

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

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

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

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

Answer 1

is my assumption right that if we have single database we don't need Event Sourcing ?

不，这个假设是错误的。

在 CQRS“传统”中，事件溯源指的是在持久数据结构中维护信息；当新信息到达时，我们将该信息添加到我们已知的信息中。换句话说，它描述了我们用来记住信息的模式。参见 Fowler 2005 .

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

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

Do I need Event Sourcing for writing message to MQ or for using Kafka ?

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

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

why do I need Event Sourcing when I have only one database and I don't care about the series of changes to the records but care only about the final state of the data,

你不知道。

事件溯源的两个最常见动机是 (a) 事件历史与您工作的领域(例如:会计)自然对齐，或 (b) 需要支持时态查询。

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