事件溯源的 CQRS 模式具有 read/write 的单个数据库
CQRS pattern with Event Sourcing having single database for read/write
我有一个单独的 SQL 服务器数据库用于读取和写入操作，我正在实施 CQRS 模式以实现代码隔离和可维护性，以便我可以将读取操作分配给团队中的少数资源并进行写入操作对于其他人，我发现使用 CQRS 似乎是一种干净的方法。
现在，每当我的数据库中的表发生 Inserts/Update/Deletes 时，我需要向其他需要了解我系统变化的系统发送消息，因为我的数据库是主数据，所以任何变化这里发生的事情需要被投射到下游系统，以便他们获得最新的数据并将其维护在他们的系统中。为此，我可能会使用 MQ 或 Kafka，因此只要有更改，我就可以生成密钥消息并放入 MQ 或使用 kafka 进行消息传递。
直到现在我还没有像我想的那样使用事件溯源，因为我没有 read/write 的多个数据库，所以我可能不需要事件溯源，我的假设是正确的，如果我们只有一个数据库我们不需要事件溯源？或事件溯源可以在利用 MQ 或 Kafka 中发挥任何作用，我的意思是，如果我使用事件溯源模式，我可以先将数据保存在主数据库中，然后使用事件溯源模式将更改写入 MQ 或使用 kafka 写入消息我一无所知在这里，如果我们可以使用 MQ 或 Kafka 的事件溯源模式。
我是否需要事件源来将消息写入 MQ 或使用 Kafka？或者在我的情况下根本不需要，因为我只有一个数据库，我不需要知道记录系统发生的一系列更新，我只关心我的主数据库中记录的最终状态然后使用 MQ 或 Kafka 将更改发送到有 CRUD 操作的下游系统，以便它们具有最新的更改。
is my assumption right that if we have single database we don't need Event Sourcing ?
不，那个假设是错误的。
在 CQRS“传统”中，事件溯源指的是在持久数据结构中维护信息；当新信息到达时，我们将这些信息追加到我们已知的信息中。换句话说，它描述了我们用来记住信息的模式。参见 Fowler 2005。
当您开始谈论 Kafka 或 Rabbit 等消息传递解决方案时，您遇到了一个不同的问题 space：您如何 在系统之间共享 信息？好吧，我们将信息放入消息中，然后将该消息从生产者传递给消费者。由于历史原因，该消息称为事件（请参阅 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) 需要支持时态查询。
如果你没有这些问题，那么你就不需要它。
我有一个单独的 SQL 服务器数据库用于读取和写入操作，我正在实施 CQRS 模式以实现代码隔离和可维护性，以便我可以将读取操作分配给团队中的少数资源并进行写入操作对于其他人，我发现使用 CQRS 似乎是一种干净的方法。
现在，每当我的数据库中的表发生 Inserts/Update/Deletes 时，我需要向其他需要了解我系统变化的系统发送消息，因为我的数据库是主数据，所以任何变化这里发生的事情需要被投射到下游系统，以便他们获得最新的数据并将其维护在他们的系统中。为此，我可能会使用 MQ 或 Kafka，因此只要有更改，我就可以生成密钥消息并放入 MQ 或使用 kafka 进行消息传递。
直到现在我还没有像我想的那样使用事件溯源，因为我没有 read/write 的多个数据库，所以我可能不需要事件溯源，我的假设是正确的，如果我们只有一个数据库我们不需要事件溯源？或事件溯源可以在利用 MQ 或 Kafka 中发挥任何作用，我的意思是，如果我使用事件溯源模式，我可以先将数据保存在主数据库中，然后使用事件溯源模式将更改写入 MQ 或使用 kafka 写入消息我一无所知在这里，如果我们可以使用 MQ 或 Kafka 的事件溯源模式。
我是否需要事件源来将消息写入 MQ 或使用 Kafka？或者在我的情况下根本不需要，因为我只有一个数据库，我不需要知道记录系统发生的一系列更新，我只关心我的主数据库中记录的最终状态然后使用 MQ 或 Kafka 将更改发送到有 CRUD 操作的下游系统，以便它们具有最新的更改。
is my assumption right that if we have single database we don't need Event Sourcing ?
不，那个假设是错误的。
在 CQRS“传统”中，事件溯源指的是在持久数据结构中维护信息；当新信息到达时，我们将这些信息追加到我们已知的信息中。换句话说，它描述了我们用来记住信息的模式。参见 Fowler 2005。
当您开始谈论 Kafka 或 Rabbit 等消息传递解决方案时，您遇到了一个不同的问题 space：您如何 在系统之间共享 信息？好吧，我们将信息放入消息中，然后将该消息从生产者传递给消费者。由于历史原因，该消息称为事件（请参阅 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) 需要支持时态查询。
如果你没有这些问题，那么你就不需要它。