该框架在很大程度上依赖于事件源，这意味着所有状态更改都将作为事件写入数据存储。”

这是完全不正确的，它不严重依赖事件源。在此框架中用于存储聚合的一种实现方式是使用事件源，但是您也可以轻松地使用提供的类来使用标准关系模型。

使用事件源会更好。

因此，您拥有所有数据的历史参考。这很好，但是使您在生产后更改域变得非常艰巨，尤其是如果您以系统“强大的可审计性”出售了客户>

我认为使用仅存储当前状态的标准关系模型不会容易得多。

该框架鼓励对数据进行非规范化，以至于有人建议>在应用程序中为每个视图都具有一个表。这使您的应用程序极难维护，特别是当原始开发人员不在时”

这与框架无关，但与使用中的架构模式（CQRS）无关。遗憾的是，拥有一个非规范化器/视图是一个好主意，因为它仍然是一个简单的对象。

因此维护很容易，因为SQL请求/插入也很容易。所以这个论点不是很强烈。一个使用1000个表模型的视图在任何地方都具有内部联接以及复杂的SQL查询怎么样？

同样，CQRS很有帮助，因为从根本上说，视图数据只是表中与视图相对应的SELECT *。

如果您以某种方式在事件处理程序之一中犯了一个错误，则唯一的选择是>“重播”事件日志，这取决于数据的大小可能需要很长时间。但是，此工具尚不存在。

我同意这一点，即目前缺乏重播事件的工具，而且这可能需要很长时间。但是，从理论上讲，仅重播事件的一部分而不是事件存储的所有内容是可能的。

重播会产生副作用，因此>开发人员会害怕这样做

重播事件有副作用->这是不正确的。对我来说，副作用意味着修改系统状态。在基于事件的CQRS应用程序中，状态存储在事件存储中。重播事件不会修改事件存储。您可以在模型的查询方面产生副作用。但是您不必担心是否犯了一个错误，因为您仍然可以更正错误并再次播放事件。

让开发人员搞混使用此框架非常容易。如果他们没有在事件中存储对域对象的更改，则下次您重播事件时，您会感到惊讶。

好吧，如果您滥用和误解了体系结构，概念等，那么我同意。但是也许问题不在于这里的框架。

你应该存储三角洲的吗？绝对值？如果您不对开发人员保持关注，那么您必定会两者兼而有之。

我可以说，对于每个系统，我都会说它与框架本身没有直接关系。就像在说：“
Java很烂，因为如果有人编写了不好的hashCode实现和equals方法，那么您可能会搞砸一切。”

对于您的评论的最后一部分，我已经看到了带有Spring框架的示例helloWorld。当然，在一个简单的示例中，它是完全没有用的。

请谨慎评论，以使概念（CQRS + EventSourcing）与框架有所不同。请有所作为。