除了缺少事件溯源的一些好处之外,在没有事件溯源的情况下将现有架构适应 CQRS 是否还有其他缺点?
我正在开发大型应用程序,开发人员应该能够在接下来的几个月内将现有架构分离为命令和查询,但是在这个阶段要求他们也添加事件源将是资源配置的一个巨大问题看法。我是否因不包括事件溯源而亵渎神明?
除了缺少事件溯源的一些好处之外,在没有事件溯源的情况下将现有架构适应 CQRS 是否还有其他缺点?
我正在开发大型应用程序,开发人员应该能够在接下来的几个月内将现有架构分离为命令和查询,但是在这个阶段要求他们也添加事件源将是资源配置的一个巨大问题看法。我是否因不包括事件溯源而亵渎神明?
事件溯源是可选的,在大多数情况下,如果过早引入,它会使事情变得更加复杂。尤其是在从遗留架构过渡时,甚至在团队没有 CQRS 经验时更是如此。
ES 的大部分优势都可以通过将事件存储在简单的事件日志中来获得。您不必放弃基于状态的持久性,(但从长远来看,您可能会放弃,因为在某些时候它将成为合乎逻辑的下一步)。
我的建议:简单是关键。一次只做一步,尤其是在引入如此戏剧性的范式转变时。从简单的 CQRS 开始,然后在您(和您的团队)习惯了新概念时引入事件日志。然后,如果需要,将您的持久性更改为事件溯源并解雇 DBA ;-)
我完全同意 Dennis,ES 不是 CQRS 的先决条件,事实上 CQRS 本身很容易实现,并且有可能真正简化您的设计。
你可以在这里找到它的流畅介绍
其次,CQRS 本身有什么好处?
更多关于 CQRS 如何使设计受益的信息可以在这里找到
也不要忘记CQRS 的无形好处
如果您仍有疑问,您可能需要阅读此内容
我们目前将 CQRS 用于中等复杂度的项目,并且发现它非常适合。我们开始使用自定义引导代码,现在开始使用Axon 框架为我们提供一些基础架构组件
如果您想知道更具体的信息,请随时 PM 我。
事件溯源模式有一个基本问题,即由于代码更改,事件存储中的事件可能不再与应用程序中的事件处理程序兼容。
话虽如此,每当您通过添加新功能来修改事件处理程序时,您都需要考虑向后兼容性。您必须确保您的代码始终可以在不同版本的代码创建的不同阶段处理相同的事件。
当你的应用程序变得更复杂时,你会发现让它向后兼容真的很痛苦。
我认为事件溯源是让人们害怕 CQRS 的原因。那是有原因的。它不自然 - 当您与现实世界中的某物交互时,您不需要了解该对象的全部历史。
“<strong>事件溯源是一个与 CQRS 完全正交的概念”(来源)——从技术上讲,如果您不使用 ES,那么您不会从 CQRS 功能中丢失任何东西。
我不知道为什么事件溯源被认为是解决一些“消息传递”相关问题的唯一基础,例如:消息的重复/丢失、消息的重新排序和数据冲突等。如果你不使用 Event采购您无法创建封装的方法来以其他方式解决此类问题。
我如何看待使用另一种数据组织原则实现 CQRS 消息传递的替代方法,您可以在此处阅读。
我建议使用“签名文档”方法,在这种方法中,您不将数据视为修改事件的组合,而是将其视为由负责用户签名的不可变部分的组合。我确信可以有很多其他的解决方案来实现消息流和数据存储。在选择您喜欢使用的商业模式时,您需要考虑到您的商业模式。
在我看来,最好的基于 CQRS 模式的框架是 Jimmy Bogard 的 MediatR,如果您在应用程序开发开始时不需要 Event Sourcing,MediatR 是正确的选择。这是存储库- https://github.com/jbogard/MediatR
在我看来,不使用 CQRS 的事件溯源是一个很大的错误。
首先,您几乎肯定会在将 Query 模型与 Command 模型同步时遇到问题。使用事件存储,如果查询端不同步,您只需要重播事件以更正它。无论如何,这就是理论!
但是使用事件溯源,您还可以存储所有实体交易的完整历史记录。这意味着您可以决定在实施后创建新的查询和视图。这些通常是使用非事件源 CQRS 无法实现的视图。我听说 Greg Young 给出了查询已从购物车中添加然后删除的商品的示例。使用事件溯源,这是可能的。没有 ES,这是不可能的,因为您只存储购物车的最终状态。