Axon Framework的真实体验

mhv*_*und 44 java cqrs axon

作为研究用于项目的CQRS的一部分,我遇到了Axon框架,我想知道是否有人有任何真实的生活经验.为了清楚起见,我问的是框架,而不是CQRS作为一种架构模式.

我的项目已经使用了Spring和Spring Integration,非常适合Axon自己的要求,但在我花了很多时间之前,我想知道是否有人有一些亲身经验.特别是我对我可能存在的陷阱感兴趣,这些陷阱在文档中并不是很明显.

小智 32

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

这完全是不真实的,它并不严重依赖于事件采购.在此框架中存储聚合的实现之一使用Event-Sourcing,但您也可以轻松地使用提供的类来使用标准关系模型.

事件采购会更好.

因此,您有所有数据的历史参考.这很不错但是在你投入生产后改变你的域名是一个非常艰巨的主张,特别是如果你在系统的"强可审计性"上出售>客户

我认为使用仅存储当前状态的标准关系模型并不容易.

该框架鼓励对数据进行非规范化,以至于某些人建议在应用程序中为每个视图设置一个表.这使您的应用程序极其难以维护,尤其是当原始开发人员不在时"

这与框架无关,而与使用的架构模式(CQRS)无关.很抱歉提到这一点,但有一个非规范化器/视图是一个好主意,因为它仍然是一个简单的对象.

因此,维护很容易,因为SQL请求/插入也很容易.所以这个论点不是很强烈.如何使用1000表模型与内部联接到处和复杂的SQL查询?

同样,CQRS有帮助,因为基本上,视图数据只是表中对应于视图的SELECT*.

如果你以某种方式在一个事件处理程序中犯了错误,你唯一的选择是"重放"事件日志,这取决于你的数据大小可能需要很长时间.然而,这种工具是不存在的.

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

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

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

使用这个框架让开发人员陷入困境是非常容易的.如果他们没有在事件中存储>对域对象的更改,那么下次重放您的事件时,您会感到惊讶.

好吧,如果你滥用和误解了架构,概念等,那么我同意你的意见.但也许问题不在于此处的框架.

你应该存三角洲吗?绝对值?如果你没有密切关注你的开发人员>你必然会最终得到这两个,你就会受到影响

我可以说,对于每个系统,我都会说它与框架本身无直接关系.这就像是说,"Java是废话,因为如果有人编写了hashCode的错误实现并且等于方法,你就会搞砸一切."

在评论的最后部分,我已经看到了像Spring框架的helloWorld样本.当然,在一个简单的例子中它完全没用.

在评论中要小心,以便在概念(CQRS + EventSourcing)和框架之间做出改变.请改变一下.

  • 现在有一种观点认为,CQRS框架**是一块废话**. - CQRS绝不应该是顶级架构, - 它具有非常具体的用例,并且不像人们想象的那样普遍. - CQRS的事情是非常特定于它不能被创建框架一概而论任何系统 - [格雷格杨上CQRS](https://www.youtube.com/watch?v=LDW0QWie21s) - [当以避免由CQRS大汉乌迪] (http://udidahan.com/2011/04/22/when-to-avoid-cqrs/) (6认同)

Per*_*der 21

既然您已经声明要为项目使用CQRS(并且我认为JVM是您的目标平台),我认为Axon Framework是一个很好的选择.

我已经建立了一个相当复杂的交易平台(不,交易样本并不复杂),我没有看到任何明显的框架缺陷.

由于我使用了EventSourcing,因此测试夹具使编写BDD样式非常容易"给定,何时,然后"测试.这使您可以将聚合视为黑盒子,并在放入某个命令时集中精力检查是否有正确的事件集.

关于陷阱:在进入之前,请确保

  1. 您已经了解了CQRS的概念.
  2. 制作所有聚合,命令处理程序,事件处理程序,传奇,命令和事件的列表(纸张,白板等).这是构建系统的难点,弄清楚它应该做什么以及如何做.在此之后,参考手册应该向您展示如何与Axon一起连接它.

一些非Axon特定点:

能够从事件重建视图存储是EventSourcing的概念,而不是Axon独有的东西,但我发现很容易创建一个服务,它将从聚合类型,聚合ID或某些事件发送给我所有事件事件类型.

能够在项目启动一年后建立一个新的报告组件,并立即从项目启动和开始时间获取数据报告是非常棒的.


dgi*_*one 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

在我们的情况下,最终它是值得的.


Mzz*_*zzl 8

OP特别询问有关Axon框架而非CQRS的陷阱.这使得这个问题难以回答,因为Axon开始是对Eric Evans着名书籍的相当忠实的实现

它的主要优点是它完全符合它所说的:它为您处理基于CQRS的设计的难点:聚合,传奇,事件采购,命令处理程序,事件处理程序,BASE一致性等.当您遵循最佳实践,您最终得到一个高度响应和水平可伸缩的应用程序.如果将其与事件源一起使用,则您的数据是完全可审计的,并且至少在理论上,您可以确定应用程序在任何给定时间点的状态.没有提供这样做的工具; 你必须自己动手.

该框架的主要开发人员非常平易近人,并且非常了解java中的高性能和可扩展计算.他倾向于在几个小时内回复邮件列表上的每个问题.这既是优势也是主要缺陷:在这个时候(2014年初),Axon框架在很大程度上取决于一个人.我想提到的其他陷阱可能更多是事件采购的结果,而不是CQRS或Axon.

提前设计您的数据模型非常仔细.虽然很容易添加,但对数据模型进行基本更改可能非常困难.如果您在数据模型中犯了一个根本性的错误,那么您的应用程序可能无法正常运行,甚至根本无法运行.例如,如果您选择树形数据模型,并且在顶部有一个长寿命聚合根,则此聚合可能会随着时间的推移累积越来越多的事件而变得非常大,并且可能需要很长时间才能加载和存储.我不知道如果这种情况继续发生,直到聚合的实例不再适合RAM,但我想可能会很糟糕.不要这样做.

另一个陷阱(事件采购相关)是,在经过多次修改后,可能会越来越难以推断聚合的状态,因为有时您不仅要记住代码当前所做的事情,还要记住它是什么在过去做过.这肯定会使事件存储的重放(一部分)重建视图表是一项非常重要的任务.

与"传统"设计相比,修复数据错误可能更困难.您通常需要创建一个命令来更改应用程序的状态,而不是简单的SQL语句.如果数据中的错误是由错误的事件处理程序引起的,那么通常只需修复错误,清除快照并让他重放聚合事件.如果您的错误导致虚假事件被应用,那么我可能会遇到更多麻烦.故障事件将保留在事件存储中,您可能必须应用一些新事件才能将数据恢复到正确状态,或更改代码以忽略或修复其行为.


Seb*_*ndt 6

我目前正在与一个在线赌场平台上工作的团队今年夏天推出我们的品牌Casumo.域和平台是使用Axon Framework构建的,到目前为止它已经为我们提供了坚实的服务.

节省了大量时间,无需构建命令处理,事件路由,事件源,快照等所需的所有基础架构,并且API非常适合使用.到目前为止,我们在框架中找到的一个错误已在12个小时后发布.Alard总是很快就新功能提出建议并讨论如何利用框架来满足您的需求.


小智 5

尽管框架本身写得足够体面,但在现实世界的项目中使用它却是一场噩梦,而选择该框架imo是导致该项目失败的主要因素。

该框架严重依赖于事件源,这意味着所有状态更改都将作为事件写入数据存储。因此,您拥有所有数据的历史参考。这很好,但是使您在投产后更改域变得非常艰巨,特别是如果您以系统的“强大的可审计性”出售了客户

您不能让运维人员对数据库进行临时更改

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

如果以某种方式在事件处理程序之一中犯了一个错误,则唯一的选择是“重播”事件日志,这取决于数据的大小可能需要很长时间。但是,此工具尚不存在。重播会产生副作用,因此开发人员会害怕这样做

让开发人员搞混使用此框架非常容易。如果它们不存储事件中域对象的更改,则下次您重播事件时,您会感到惊讶。你应该存储三角洲的吗?绝对值?如果您不对开发人员保持关注,那么您必然会两者兼而有之,您会感到厌恶。

几乎没有采用此框架,因此使用Google搜索来解决问题不会有任何好处

即使该框架尚不支持发行版,也要牢记这一点,因此使用api是一件痛苦的事情。默认情况下,触发事件是异步的,如果您想检查是否在执行命令时引发了异常(例如重复的用户名异常),则需要将侦听器传递给将来的命令处理程序,然后等待将来的结果进入,处理所有检查的异常,interuptedexception等,然后您就可以获取将来抛出的异常。当然从api 中看不到命令可以引发的异常。击败检查异常的目的

查看一些示例应用程序。我以某种方式需要工作监听器来创建通讯录应用程序?我的天啊...

  • @jackjin他是Martin fower,而不是福勒。 (7认同)