如何让客户方便地使用事件溯源?事件溯源有什么好处?- daryush_d

20-05-16 banq

问:“如何使客户方便使用事件溯源Eventsourcing?”

答:“只要不告诉他们,他们应该不在乎”

更多答案:

我有一个合理的经验法则来决定您的业务领域是否适合事件溯源:是否涉及律师,会计师或审计师?

历史记录在物联网,运输,商业,ERP,CRM,旅行,任何形式的预订等方面都非常有价值。

经过10年的电子商务,在金钱或其他一切有风险的事情上,我总是会选择ES。

我认为将事件源与历史记录收集用于审计目的有点误导。如果您没有很好定义/稳定的事件格式,更改要求或有时需要及时返回(例如,不是“仅追加”),则从事件重播会更加困难。

历史可以像版本化文档一样保存。但是捕获系统行为是非常宝贵的。

我想知道我们是否在这里缺少一些假设前提,可能的前提是,在使用ES并将系统投入生产之前,您已经对领域和稳定的业务模型具有公认的,非常好的理解?因为我的经验是,这比听起来要难。

我同意,由于范式的不断变化和基本模型的变化,对于不断发展的业务而言,未经验证的领域模型对事件源来说是一团糟。但这并不经常发生。我今天在会议上提到了它。

我的经验是,ES系统实际上比传统系统更容易发展。在传统系统中,我们通过假装旧数据发生在新模型中进行迁移。这种迁移是痛苦的,昂贵的,有风险的,并且通常是不可逆的。我们刚好习惯了那种痛苦。或者我们只是不迁移,而只是添加更多的差劲CRU操作,直到它变成无法理解的遗留混乱,这也是我们习惯的痛苦。在ES中,更改是明确的:我们将旧数据保留在旧模型中。该事件在此时间点在此模型下运行,没有任何影响。另一个好处:我们的事件历史记录可以跟踪模型更改。GDPRWasActivated是一个域事件,UpgradedCustomerToNewMobilePlan也是如此。模型更改成为模型本身的第一流。同样,有明确的基本复杂性。

banq注:当有多个来源更改一个状态,比如设置为true或false,如果你将这个状态字段设计到数据库表中,那必须所有来源都需要知道有这个表字段,一旦表结构改变,影响全面。但是使用事件溯源,无论内部自己的操作,还是加载的第三方插件,或者调用第三方API,所有修改聚合状态的事件都会被放入事件日志,那么我们关心的状态是true和false可以从这个事件日志中追溯到,也许这是过了N多年以后的事情。

 

    

猜你喜欢