我有一个用于读写操作的SQL Server数据库，我正在实现CQRS模式以实现代码分离和可维护性，这样我就可以将读操作分配给团队中的少数资源，并将写操作分配给其他资源，我认为使用CQRS似乎是一种干净的方法。
现在，每当我的数据库中的表上发生插入/更新/删除时，我都需要向其他需要了解我的系统中的更改的系统发送消息，因为我的数据库是主数据，所以这里发生的任何更改都需要投影到下游系统，以便他们获得最新数据并在系统中进行维护。为此，我可以使用MQ或Kafka，因此无论何时发生更改，我都可以生成密钥消息并放入MQ或使用Kafka进行消息传递。
到目前为止，我还没有像我想的那样使用事件源，因为我没有多个读/写数据库，所以我可能不需要事件源，我的假设是正确的吗？或者Event Sourcing可以在使用MQ或Kafka中发挥任何作用，我的意思是，如果我使用Event Sourcng模式，我可以首先将数据保存在master数据库中，并使用Event Sounding模式将更改写入MQ或使用Kafka写入消息。如果我们可以将Event Sourcingpattern用于MQ或Kavka，我在这里一无所知。
向MQ写入消息或使用Kafka需要事件源吗？或者在我的情况下根本不需要，因为我只有一个数据库，我不需要知道记录系统发生的一系列更新，我所关心的只是主数据库中记录的最终状态，然后使用MQ或Kafka将更改发送到有CRUD操作的下游系统，以便它们具有最新的更改。
我的假设是正确的吗？如果我们有一个数据库，我们就不需要事件源？
不，这种假设是错误的。
在CQRS"中；传统">事件源是指在持久数据结构中维护信息；当新的信息到达时，我们将该信息附加到我们已经知道的信息中。换句话说，它描述了我们用来记忆信息的模式。参见Fowler 2005。
当你开始谈论像Kafka或Rabbit这样的消息传递解决方案时，你就处于一个不同的问题空间：你如何在系统之间共享信息？好吧，我们将信息放入一个消息中，并将该消息从生产者传递给消费者。由于历史的原因，这种信息被称为事件(参见Hohpe等人(。
两种不同的想法，很容易混淆。当CQRS的人谈论事件来源时，他们的意思与卡夫卡的人谈论活动来源的意思不同。
向MQ写入消息或使用Kafka需要事件源吗？
即使您选择了事件来源以外的其他记忆策略，无消息仍然有效。
修改你的模型是完全合理的；"就位"；，然后发布一条消息，宣布情况发生了变化。
为什么我只有一个数据库，而我不关心记录的一系列更改，只关心数据的最终状态，
你没有。
事件来源的两个最常见动机是：(a(事件历史与您工作的领域(例如：会计(自然一致，或者(b(需要支持时间查询。
如果你没有这些问题，那么你就不需要它。