Axon框架的真实生活经验[已关闭]

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

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

通过事件采购，情况会更好。

因此，您拥有所有数据的历史参考。这很好，但是在您投入生产后更改>域是一个非常艰巨的提议，特别是如果您>系统“强大的可审计性”上的客户“出售”

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

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

这与框架无关，但与正在使用的体系结构模式 （CQRS） 无关。很抱歉提到这一点，但有一个非规范化器/视图是一个好主意，因为它仍然是一个简单的对象。

所以维护很容易，因为SQL请求/插入也很容易。所以这个论点不是很有力。使用 1000 个表模型的视图，其中内部连接无处不在，并且具有复杂的 SQL 查询，该视图怎么样？

同样，CQRS 会有所帮助，因为基本上，视图数据只是表中与视图对应的 SELECT * 。

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

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

重播可能会有副作用，所以>开发人员会害怕这样做

重播事件有副作用 - >这是不真实的。对我来说，副作用意味着修改系统的状态。在事件源 CQRS 应用程序中，状态存储在事件存储中。重播事件不会修改事件存储。您可能会对模型的查询端产生副作用 Yes。但是你不在乎你是否犯了一个错误，因为你仍然能够纠正它并再次重播事件。

开发人员很容易使用此框架搞砸。如果他们没有在事件中存储>域对象的更改，那么下次重播事件时，您将获得>奖励。

好吧，如果你误用和误解了架构，概念等，那么好吧，我同意你的观点。但也许问题不在于这里的框架。

你应该存储达美的吗？绝对值 ？如果你不密切关注你的开发人员>你注定会同时拥有两者，你会被f***ed

我可以说，对于每个系统，我会说它与框架本身直接无关。这就像说，“Java是废话，因为如果有人编写了一个糟糕的哈希代码实现并等于方法，你可能会搞砸一切。

对于您评论的最后一部分，我已经看到了像HelloWorld和Spring框架这样的示例。当然，在一个简单的例子中，它是完全无用的。

在注释中要小心，以便在概念（CQRS + 事件溯源）和框架之间做出区分。请有所作为。

既然你已经说过你想在你的项目中使用CQRS（我假设JVM是你的目标平台），我认为Axon Framework是一个很好的选择。

我已经在上面构建了一个相当复杂的交易平台（不，交易样本并不复杂），我没有看到框架的任何明显缺陷。

由于我使用事件溯源，测试夹具使得编写BDD样式的“给定，何时，然后”测试变得非常容易。这使您可以将聚合视为黑匣子，并专注于检查在输入某个命令时是否出现了正确的事件集。

关于陷阱：在跳进去之前，请确保

1. 您已经弄清楚了CQRS的概念。
2. 列出所有聚合、命令处理程序、事件处理程序、sagas、命令和事件的列表（纸张、白板等）。这是构建系统，弄清楚它应该做什么以及如何做的困难的部分。在此之后，参考手册应向您展示如何将其与Axon连接在一起。

一些非Axon特定点：

能够从事件重建视图存储是事件溯源的一个概念，而不是Axon独有的东西，但我发现创建一个服务很容易，该服务将从聚合类型，聚合ID或某个事件类型向我发送所有事件。

能够在项目启动一年后构建新的报告组件，并从项目启动之时起立即获得数据报告，这真是太棒了。