除了缺少事件源的一些好处外，在没有事件源的情况下将现有架构调整为CQRS还有其他缺点吗？
我正在开发大型应用程序，在接下来的几个月里，开发人员应该能够处理将现有架构分离为命令和查询的问题，但从资源角度来看，要求他们在现阶段也添加事件源将是一个巨大的问题。我不参加活动采购是在亵渎神明吗？
事件来源是可选的，在大多数情况下，如果过早引入，会使事情变得更加复杂。尤其是在从传统体系结构过渡时，甚至在团队没有CQRS经验的情况下。
ES的大部分优势都可以通过将事件存储在一个简单的事件日志中来获得。你不必放弃基于状态的持久性（但从长远来看，你可能会放弃，因为在某个时候，它将成为合乎逻辑的下一步）。
我的建议是：简单是关键。一步一个脚印，尤其是在引入如此戏剧性的范式转变时。从简单的CQRS开始，然后在您（和您的团队）已经习惯了新概念时引入事件日志。然后，如果需要，将持久性更改为事件源，并解雇DBA；-）
我完全同意Dennis的观点，ES不是CQRS的先决条件，事实上CQRS本身很容易实现，并且有可能真正简化您的设计。
你可以在这里找到一个流畅的介绍
其次，CQRS本身带来了什么好处？
- 通过消除所有查询问题简化域对象
- 使代码具有可扩展性，您的查询是分离的，并且可以轻松调整
- 在迭代产品设计时，您可以添加/删除/更改单独的命令/查询，而不是处理更大的结构作为一个整体（例如实体、集合、模块）
- 命令和查询产生了一个众所周知的词汇表领域专家。其他架构模式（例如，管道和过滤器，演员）使用可能更难理解的术语和概念非程序员
- 限制ORM的使用（如果你使用的话），我觉得ORM带来了如果您尝试使用它们进行查询抽象是漏洞百出和沉重的，试图调整它们是一场噩梦：）。只在命令端使用ORM会让事情变得更糟更简单、简单的旧SQL最适合查询，最需要的可能是使用一个简单的库将结果集转换为DTO
更多关于CQRS如何有利于设计的信息，请点击
也不要忘记CQRS 的无形好处
如果你仍然有疑问，你可能想阅读这个
我们目前将CQRS用于中等复杂度的项目，并发现它非常适合。我们一开始使用自定义的引导程序代码，现在已经使用Axon框架为我们提供了一些基础设施组件
如果你想知道任何更具体的事情，请随时联系我。
事件源模式存在一个根本问题，即由于代码更改，事件存储中的事件可能不再与应用程序中的事件处理程序兼容。
也就是说，每当您通过添加新功能来修改事件处理程序时，都需要考虑向后兼容性。您必须确保您的代码始终能够在由不同版本的代码创建的不同阶段处理相同的事件。
当你的应用程序变得更加复杂时，你会发现让它向后兼容真的很痛苦。
我认为事件来源是让人们害怕CQRS的原因。这是有原因的。这是不自然的——当你在现实世界中与某个物体互动时，你不需要了解这个物体的全部历史。
"事件来源是一个与CQRS完全正交的概念"（来源）-从技术上讲，如果你不使用ES，你就不会从CQRS功能中获得任何东西。
我不知道为什么Event Sourcing被认为是解决一些"消息传递"相关问题的唯一基础，例如：消息的重复/丢失、消息的重新排序和数据冲突等。如果你不使用Event Sourcng，你就不能创建封装的方法来以其他方式解决这些问题。
我如何看待使用另一个数据组织原则实现CQRS消息传递的替代方法，您可以在此处阅读。
我提出了"签名文档"方法，即您不将数据视为修改事件的组成，而是将数据视为由负责用户签名的不可变部分的组成。我相信可以有很多其他的解决方案来实现消息流和数据存储。在选择你喜欢使用的商业模式时，你需要考虑到你的商业模式。
在我看来，最好的基于CQRS模式的框架是Jimmy Bogard的MediatR。如果您在应用程序开发之初不需要事件源，MediatR是正确的选择。这是存储库-https://github.com/jbogard/MediatR
在我看来，您没有在CQRS中使用事件源，这是一个很大的错误。
首先，您几乎肯定会在将Query模型与Command模型同步时遇到问题。对于事件存储，如果查询端出现不同步，只需重播事件即可纠正。这就是理论！
但使用Event Sourcing，您还可以存储所有实体交易的完整历史记录。这意味着您可以决定在实现后创建新的查询和视图。这些通常是使用非事件源CQRS不可能实现的视图。我听Greg Young举了一个查询购物车中添加然后删除的商品的例子。有了Event Sourcing，这是可能的。没有ES是不可能的，因为你只存储购物车的最终状态。