.net - 具有事件驱动架构但没有事件溯源的 CQRS

Question

在发布此之前，我参考了许多网站和学习平台，但看到了使用事件源开发 CQRS 的类似模式。同样，要进行适当的事件，您需要遵循 DDD 模式。我有以下问题。

1. 我们可以通过从写入模型发布事件并使用事件处理程序在读取模型中使用它并更新读取数据库来保持读取和写入数据库同步吗
2. 如果我的要求是只查看最新数据，为什么需要事件溯源和事件重播
3. 我可以在事件到达事件处理程序时管理数据审计
4. 如果出现竞争条件，我可以根据时间戳对消息进行版本控制。
5. 请通过执行步骤 1,3 和 4 进行解释，我是否仍然遵循 CQRS 模式？

仅供参考，我使用 .NetCore 3.1、AWS Lambda 服务、MassTransit 作为 MessageBus 和 SQS 作为传输。

提前致谢。

标签： .netasp.net-coredesign-patternscqrs

Answer 1

只要您有用于读取和写入的单独数据模型，您就在遵循 CQRS。事件溯源不是严格要求的。

请注意，在应用程序中以保持读取端与写入端预期最终一致性的方式完成 1 是相当困难的。当且仅当写入数据库的更新成功时，您需要确保发布事件（即，永远不会出现您发布但不更新的情况，也不会出现您更新但不发布的情况：如果其中任何一种都可能发生，则不能保证最终的一致性）。例如，如果您的应用程序进行更新并且如果成功，则发布事件，如果进程在更新和发布之间崩溃（或者您从数据库中获得网络分区，或者您的 lambda 超出其时间限制......）会发生什么?

确保最终一致性的 2 个最佳方法是

• 通过订阅已发布的事件流来更新写入端数据库
• 在写入端 DB 上使用更改数据捕获来生成要发布的事件

第一个至少非常接近事件溯源（有人可以争论任何一种方式：我会说这取决于您的设计将发布的事件流视为事实来源的程度）。其次，请记住，您基本上已经失去了围绕该事件发生的所有上下文领域知识：您只看到数据库表示模型的变化。

事件溯源和 CQRS 相辅相成（你也可以不做 CQRS 也可以事件溯源，虽然只有在某些应用中，不做 CQRS 的 ES 才是实用的）；事件溯源倾向于让您将域保持在前端和中心，并且由于它是仅附加的，因此它是您可以拥有的最优化的写入模型。