Axon Framework的真实体验 [英] Real life experience with the Axon Framework

问题描述

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

As part of researching CQRS for use with a project, I ran across the Axon Framework, and I was wondering if anyone has any real life experience with it. Just to be clear, I'm asking about the framework, not CQRS as an architectural pattern.

我的项目已经使用了Spring和Spring Integration，非常适合Axon自己的要求，但在我花了很多时间之前，我想知道是否有人有第一手经验。特别是我感兴趣的可能是文档中没有明显的陷阱。

My project already uses Spring and Spring Integration which fits nicely with Axon's own requirements, but before i dedicate a lot of time to it, I would like to know if anyone has some first hand experience. In particular I'm interested i possible pitfalls that are not immediately apparent from the documentation.

推荐答案

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

The framework relies heavily on eventsourcing, which means that all state changes are >written to the data store as events. "

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

This is completely untrue, it does not rely heavily on event-sourcing. One of the implementations for storing the aggregate in this framework use Event-Sourcing but you can easily use also the classes provided to use a standard relational model.

事件采购更好。

所以你有一个关于你所有数据的历史参考。这很不错但是在你投入生产之后改变你的域名是一个非常令人生畏的主张，特别是如果你出售>系统上的客户强可审计性

So you have a historical reference of all your data. This is nice but makes changing your >domain after you've gone in production a very daunting proposition especially if you sold >the customer on the system's "strong auditability" "

我不认为使用标准关系模型会更容易只存储当前状态。

I don't think it is a lot easier with a standard relational model that only stores the current state.

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

The framework encourages denormalizing your data, to the point that some have suggested >having a table per view in the application. This makes your application extremely >difficult to maintain, especially when the original developers are gone"

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

This is unrelated to the framework but to the architectural pattern in use (CQRS). And sorry to mention that but having one denormalizer/view is a good idea as it stays a simple object.

所以维护很容易，因为SQL请求/插入也很容易。
所以这个参数不是很强。
如果一个视图使用1000表模型，内部连接到处都是复杂的SQL查询？

So maintenance is easy because SQL request/insertion as also easy. So this argument is not very strong. How about a view which uses a 1000 tables model with inner joins everywhere and complex SQL queries?

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

Again, CQRS helps because, basically, the view data is just a SELECT * from the table which correspond to the view.

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

if somehow you made a mistake in one of the eventhandlers, your only option is to >"replay" the eventlog, which depending on the size of your data can take a very long >time. The tooling for this however is non-existent.

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

I agree on the point that currently there is a lack of tooling to replay events and that this can take a long time. However, it is theoretically possible to only replay a portion of the event and not all the content of the event store.

重播可以有一面效果，所以>开发人员害怕这样做

Replaying can have side effects, so >developers become scared of doing it

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

Replaying event have side effects -> that's untrue. For me side effects means modifying the state of the system. In an event-sourced CQRS application, the state is stored in the event-store. Replaying the events does not modify the event store. You can have side effect on the query side of the model yes. But you don't care if you have made a mistake because you are still able to correct it and replay the event once again.

它是开发人员使用这个框架非常容易搞砸。如果他们没有在事件中存储>对域对象的更改，那么下次重放您的事件时，您会感到惊讶。

it's extremely easy to have developers mess up using this framework. if they don't store >changes to domain objects in events, next time you replay your events you are in for a >surprise.

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

Well if you misused and misunderstand the architecture, the concept, etc. then ok I agree with you. But perhaps the problem is not the framework here.

你应该存储delta吗？绝对值？如果你没有密切关注你的开发者>你必然会得到两者并且你将会被罚款

Should you store delta's ? absolute values ? if you don't keep tabs on your developers >you are bound to end up with both and you will be f***ed

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

I can say that for every system I would say that it's unrelated directly to the framework itself. It's like saying, "Java is crap because you can messed up everything if someone codes a bad implementation of hashCode and equals methods."

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

And for the last part of your comment, I already seen samples like helloWorld with the Spring framework. Of course it is completely useless in a simple example.

在评论中要小心，以便在概念（CQRS + EventSourcing）和框架之间产生影响。请有所作为。

Be careful in your comment to make a difference between the concept (CQRS + EventSourcing) and the framework. Make a difference please.

这篇关于Axon Framework的真实体验的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！