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)和框架。请改变。