作为研究用于项目的CQRS的一部分，我遇到了Axon Framework，我想知道是否有人有任何真实的生活经历。为了清楚起见，我问的是框架，而不是CQRS作为一种架构模式。
我的项目已经使用了Spring和Spring Integration，非常符合Axon自己的要求，但在我花了很多时间之前，我想知道是否有人有亲身体验。特别是我对我可能存在的陷阱感兴趣，这些陷阱在文档中并不是很明显。
答案 0 :(得分：31)
框架在很大程度上依赖于事件源，这意味着所有状态更改都将作为事件写入数据存储。 “
这完全是不真实的，它并不严重依赖事件采购。在此框架中存储聚合的实现之一使用Event-Sourcing，但您也可以轻松地使用提供的类来使用标准关系模型。
事件采购会更好。
因此，您有所有数据的历史参考。这很不错，但是在你投入生产后改变你的＆gt;域是一个非常令人生畏的主张，特别是如果你出售＆gt;系统中的客户“强大的可审计性”“
我不认为使用仅存储当前状态的标准关系模型会更容易。
该框架鼓励对您的数据进行非规范化，以至于某些人建议＆gt;在应用程序中每个视图都有一个表。这使得您的应用程序非常难以维护，尤其是当原始开发人员不在时“
这与框架无关，而与使用的架构模式（CQRS）无关。 很遗憾地提到这一点，但有一个反规范器/视图是一个好主意，因为它仍然是一个简单的对象。
因此，维护很容易，因为SQL请求/插入也很容易。 所以这个论点不是很强烈。 如果一个视图使用1000表模型，内部连接到处都是复杂的SQL查询？
同样，CQRS有帮助，因为基本上，视图数据只是表格中对应于视图的SELECT *。
如果你在其中一个事件处理程序中犯了错误，你唯一的选择是＆gt;“重播”事件日志，这取决于你的数据大小可能需要很长的时间。然而，这种工具是不存在的。
我同意目前缺乏重播事件的工具，这可能需要很长时间。但是，理论上可以只重播事件的一部分而不是事件存储的所有内容。
重播会产生副作用，因此＆gt;开发人员害怕这样做
重播事件有副作用 - ＆gt;这是不真实的。对我来说，副作用意味着修改系统的状态。在事件源CQRS应用程序中，状态存储在事件存储中。重播事件不会修改事件存储。 您可以在模型的查询方面产生副作用。但你不在乎你是否犯了错误，因为你仍然可以纠正它并再次重播该事件。
让开发人员使用这个框架搞得一团糟。如果他们没有在事件中存储＆gt;对域对象的更改，那么下次您重播事件时，您会遇到＆gt;惊喜。
如果您误用并误解了架构，概念等等，那么我同意你的意见。但也许这个问题不是这里的框架。
你应该存储delta吗？绝对值？如果你没有密切关注你的开发者＆gt;你一定会最终得到这两个并且你将会被发现
我可以说，对于每个系统，我都会说它与框架本身无直接关系。这就像是说，“Java是废话，因为如果有人编写了hashCode的错误实现并且等于方法，你就会搞砸一切。”
对于评论的最后一部分，我已经在Spring框架中看到了像helloWorld这样的示例。 当然，在一个简单的例子中它完全没用。
在评论中要小心，以便在概念（CQRS + EventSourcing）和框架之间做出改变。请改变一下。
答案 1 :(得分：20)
既然您已经声明要为项目使用CQRS（并且我认为JVM是您的目标平台），我认为Axon Framework是一个很好的选择。
我已经建立了一个相当复杂的交易平台（不，交易样本并不复杂），我没有看到任何明显的框架缺陷。
由于我使用了EventSourcing，因此测试夹具使得“给定，何时，然后”测试可以很容易地编写BDD样式。这使得您可以将聚合视为黑盒子，并专注于在您输入某个命令时检查是否有正确的事件集。
关于陷阱：在进入之前，请确保
一些非Axon特定要点：
能够从事件重建视图存储是EventSourcing的概念，而不是Axon独有的东西，但我发现创建一个服务将很容易从聚合类型，聚合id发送给我所有事件或某种事件类型。
能够在项目启动一年后建立一个新的报告组件，并立即从项目启动时开始获取数据报告，这非常棒。
答案 2 :(得分：15)
我一直在为一家大银行开发的复杂项目中使用AxonFramework超过一年。
要求苛刻，客户期望很高，发布时间缩短。
我选择了AxonFramework，因为在项目开始的时候，它是Java中最完整，最好的CQRS实现，设计精良，易于集成，测试和扩展。
一年多之后，我认为这些考虑因素仍然有效且最新。
另一个考虑因素引导了我的选择：我希望这个困难项目的承诺成为我和团队其他成员的培训机会。
我们开始使用AxonFramework 1.0版进行开发，并在发布新版本时转移到1.4版。
我们团队使用CQRS的经验以及AxonFramework提供的实施绝对是积极的。
它为我们提供了一致且统一的方式来开发引导我们并让您感到放心的每个功能。
如果没有它，应用程序的某些功能将会变得更加复杂。 我主要指的是需要处理的各种长时间运行的流程以及相关的补偿逻辑，还指的是在事件驱动的体系结构中很好地适应和解耦的许多业务逻辑部分。由CQRS推动。
我们的选择是在写模型中保守，所以我们更喜欢基于JPA的持久性而不是事件源的持久性。
查询模型由视图组成。我们已尝试在必要时使用中间视图确保每个视图包含单个页面中的所有必需数据。
无论如何，我们在应用事件源时开发了写模型，因此我们专门通过事件来修改聚合状态。当客户要求一个非常复杂的聚合的克隆功能时，只需要将源事件（使用uuid已翻译）重放到一个全新的实例 - 在这种情况下，向下的事件是向上转发的事件（但这个功能是即将到来的2.0版本大大改进了）。
正如在开发过程中的每个项目中一样，我们在代码中发现了很多错误，但也发现了应该成熟稳定的组件，比如应用服务器，IoC容器，缓存，工作流引擎和一些在任何大型J2EE应用程序中都可以轻松找到的其他库。
正如任何其他人类产品AxonFramework也不能免受bug的影响，但令人惊讶的是，对于像这样的年轻和小众项目，它们很少，而不是关键，并且很快就被新版本解决了。
作者在邮件列表上提供的直接支持是另一个非常宝贵的功能，在我遇到麻烦时帮了我很多忙。
该应用程序于一年前发布，目前正在维护并正在积极开发新功能。
客户满意并要求更多。
何时使用AxonFramework更多的是何时使用CQRS。有关回复，请返回官方文档：http://www.axonframework.org/docs/1.4/introduction.html#d4e51
在我们的案例中，确实值得。
答案 3 :(得分：7)
OP专门询问与Axon框架有关的缺陷而不是CQRS。这使得这个问题难以回答，因为Axon开始是Eric Evans
对这本着名书籍的相当忠实的实施。主要优势在于它完全符合它在锡上的说法：它为您处理基于CQRS的设计的难点部分：聚合，传奇，事件采购，命令处理程序，事件处理程序，BASE一致性等。当您遵循最佳实践，您最终会得到高度响应且可横向扩展的应用程序。如果将其与事件源一起使用，则您的数据是完全可审计的，并且至少在理论上，您可以确定应用程序在任何给定时间点的状态。没有提供这样做的工具;你必须自己动手。
该框架的主要开发人员非常平易近人，对java中的高性能和可伸缩计算主题非常了解。他倾向于在几个小时内回复邮件列表上的每个问题。这既是优势也是主要缺陷：在这个时候（2014年初），Axon框架在很大程度上取决于一个人。我想提到的其他陷阱可能更多是事件采购的结果，而不是CQRS或Axon。
预先非常仔细地设计您的数据模型。虽然很容易添加，但对数据模型进行基本更改可能非常困难。如果您在数据模型中犯了一个根本性的错误，那么您的应用程序可能无法正常运行，甚至根本无法运行。例如，如果您选择树形数据模型，并且在顶部有一个长寿命聚合根，则此聚合可能会随着时间的推移累积越来越多的事件而变得非常大，并且可能需要很长时间才能加载和存储。我不知道如果这种情况继续发生，直到聚合的实例不再适合RAM，但我想可能会很糟糕。不要这样做。
另一个陷阱（事件采购相关）是，在经过多次修订后，可能会越来越难以推断聚合的状态，因为有时您不仅要记住代码当前所做的事情，而是它也是过去所做的。这肯定会使事件存储的重放（一部分）重建视图表是一项非常重要的任务。
修复数据错误比使用“传统”设计更困难。您通常需要创建命令来更改应用程序的状态，而不是简单的SQL语句。如果数据中的错误是由错误的事件处理程序引起的，那么通常只需修复错误，清除快照并让他重放聚合事件。如果您的错误导致虚假事件被应用，那么我可能会遇到更多麻烦。故障事件将保留在事件存储中，您可能必须应用一些新事件才能将数据恢复到正确状态，或更改代码以忽略或修复其行为。
答案 4 :(得分：6)
我目前正在与一个在线赌场平台合作的团队今年夏天推出我们的品牌Casumo。域和平台是使用Axon Framework构建的，到目前为止它已经为我们提供了坚实的服务。
节省了大量时间，无需构建命令处理，事件路由，事件源，快照等所需的所有基础架构，并且API非常适合使用。到目前为止，我们在框架中找到的一个错误已在12个小时后发布.Alard总是很快就新功能提出建议并讨论如何利用框架来满足您的需求。
答案 5 :(得分：5)
虽然框架本身写得足够好，但在现实世界项目中使用它一直是一场噩梦，而这个框架imo的选择是该项目失败的主要因素。
框架在很大程度上依赖于事件源，这意味着所有状态更改都将作为事件写入数据存储。因此，您拥有所有数据的历史参考。这很不错，但是在您投入生产后改变您的域名是一个非常艰巨的主张，特别是如果您在系统的“强可审计性”上出售客户
你不能让操作人员对数据库进行临时更改
该框架鼓励对数据进行非规范化，以至于某些人建议在应用程序中为每个视图设置一个表。这使得您的应用程序极难维护，尤其是当原始开发人员不在时
如果你以某种方式在一个事件处理程序中犯了错误，你唯一的选择是“重放”事件日志，这取决于你的数据大小可能需要很长时间。然而，这种工具是不存在的。重播可能会产生副作用，因此开发人员害怕这样做
让开发人员使用这个框架搞得一团糟。如果他们没有在事件中存储域对象的更改，那么下次重放您的事件时，您会感到惊讶。你应该存三角洲吗？绝对值？如果你没有密切关注你的开发人员，那么你最终会选择这两个开发者，你将会被视为
实际上没有采用这个框架，所以谷歌搜索答案对你没有任何好处
即使框架还没有支持发行版，它也是用它来编写的，而api是因为它而难以使用。默认情况下，关闭事件是异步的，如果你想检查是否引发了执行命令的异常，说一个重复的用户名异常，你需要将一个监听器传递给你的命令提供者，这是一个未来，然后你等待未来的结果进来，处理任何已检查的异常，interuptedexception等，然后你可以获取从未来抛出的异常。当然哪个命令可以引发的异常在api中并不明显。击败检查异常的目的
查看一些example apps。我不知何故需要一个工作单元监听器来创建一个地址簿应用程序？我的天啊......