java axon教程_java – Axon框架的现实生活经验

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

这是完全不真实的，它不会严重依赖事件来源。在这个框架中存储聚合的实现之一使用Event-Sourcing，但是你也可以很容易地使用提供的类来使用标准的关系模型。

它只是更好地与事件采购。

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” “

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

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)无关。

对不起，提到，但有一个denormalizer /视图是一个好主意，因为它保持一个简单的对象。

所以维护很容易，因为SQL请求/插入也很容易。

所以这个论点不是很强。

使用1000个表模型的视图如何使用内部连接无处不在和复杂的SQL查询？

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

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.

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

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

重放事件有副作用 – >这是不真实的。对于我来说，副作用意味着修改系统的状态。在事件源CQRS应用程序中，状态存储在事件存储中。重播事件不会修改事件存储。

你可以在模型的查询端有副作用。但你不在乎你是否犯了一个错误，因为你仍然能够纠正它，并再次重播事件。

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.

如果你误用和误解了建筑，概念等，那么确定我同意你的意见。但也许问题不是这里的框架。

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和equals方法，你可以搞砸一切。

而对于你的评论的最后一部分，我已经看到样本像helloWorld与Spring框架。

当然，在一个简单的例子中它是完全无用的。

在注释中要小心，以区分概念(CQRS EventSourcing)和框架。请改变。