除了遗漏事件采购的一些好处之外，在没有事件采购部件的情况下使现有架构适应CQRS还有其他任何缺点吗？
我正在研究大型应用程序，开发人员应该能够在接下来的几个月内将现有架构分离为命令和查询，但要求他们在此阶段添加事件源也是一个巨大的问题从资源的角度来看。我是不是因为不包括事件采购而亵渎神灵？
答案 0 :(得分：56)
事件采购是可选的，在大多数情况下，如果过早引入，则会使事情变得复杂。特别是在从传统架构过渡时，甚至在团队没有使用CQRS的情况下更多。
通过将事件存储在简单的事件日志中，可以获得归因于ES的大多数优势。你不必放弃基于状态的持久性，（但从长远来看，你可能会这样做，因为在某些时候它将成为合乎逻辑的下一步）。
我的建议：简单是关键。一步一步，特别是在引入如此戏剧性的范式转变时。从简单的CQRS开始，然后在您（和您的团队）习惯了新概念时引入事件日志。然后，如果完全需要，将持久性更改为Event Sourcing并激活DBA; - ）
答案 1 :(得分：15)
我完全赞同Dennis，ES不是CQRS的先决条件，事实上CQRS本身很容易实现，并且有可能真正简化您的设计。
您可以找到它的简单介绍here
其次，CQRS本身带来哪些好处？
有关CQRS如何设计的更多信息，请访问here
另外请不要忘记non tangible benefits of CQRS
如果您仍有疑问，可能需要read this
我们目前将CQRS用于中等复杂度的项目，并且发现它非常适合。我们开始使用custom bootstrap code，现在转而使用Axon Framework为我们提供一些基础架构组件
如果您想了解更具体的内容，请随时与我联系。
答案 2 :(得分：13)
事件源模式存在一个基本问题，即由于代码更改，事件存储中的事件可能与您的应用程序中的事件处理程序不兼容。
话虽这么说，每当您通过添加新功能修改事件处理程序时，您都需要考虑向后兼容性。您必须确保您的代码始终能够处理由不同版本的代码创建的不同阶段中的相同事件。
当你的应用程序变得更加复杂时，你会发现使它向后兼容会非常痛苦。
答案 3 :(得分：5)
我认为事件采购是让人们害怕CQRS的原因。这是有原因的。它不自然 - 当你与现实世界中的某些东西互动时，你不需要获得关于这个对象的完整历史。
“事件采购与CQRS完全正交的概念”（source） - 从技术上讲，如果您不使用ES，则不会从CQRS功能中消失任何内容。
我不知道为什么事件采购被认为是解决某些＆＃34;消息传递的唯一基础＆＃34;相关的问题，如：消息的重复/缺失，消息的重新排序和数据冲突等。如果你不使用事件采购，你不能创建封装的方法来解决其他问题。
我如何看待使用其他数据组织原则实施CQRS消息传递的其他方法，您可以阅读here。
我建议＆＃34;签署文件＆＃34;将数据视为修改事件的组合，而不是由负责用户签署的不可变部分的组合。我确定可以有很多其他解决方案来实现消息流和数据存储。在选择您想要使用的商业模式时，您需要考虑您的商业模式。
答案 4 :(得分：0)
在我看来，最好的基于CQRS模式的框架是Jimmy Bogard的MediatR，如果在应用程序开发的开始阶段不需要事件源，那么MediatR是正确的选择。这是存储库-https://github.com/jbogard/MediatR
答案 5 :(得分：-1)
在我看来，你没有使用CQRS的事件采购，这是一个很大的错误。
首先，您几乎肯定会遇到将Query模型与Command模型同步的问题。使用事件存储，如果查询端不同步，您只需重放事件以进行更正。无论如何，这就是理论！
但是通过Event Sourcing，您还可以存储所有实体交易的完整历史记录。这意味着您可以决定在实施后创建新的查询和视图。这些通常是非事件源CQRS无法实现的视图。我听说Greg Young举例说明了从购物车中添加，然后删除的项目。通过Event Sourcing，这是可能的。没有ES，这是不可能的，因为你只存储购物车的最终状态。