事件来源：触发其他事件的事件&重建状态 [英] Event Sourcing: Events that trigger others & rebuilding state

问题描述

我正在努力通过重放EventStore中的事件来重建模型时应该发生的事情，特别是当事件可能触发其他事件发生时。

I'm struggling to get my head around what should happen when rebuilding the model by replaying events from the EventStore, in particular when events may trigger other events to happen.

例如，已购物10次的用户应提升为首选客户，并收到一封向他们提供某些促销的电子邮件。

For example, a user who has made 10 purchases should be promoted to a preferred customer and receive an email offering them certain promotions.

我们显然不希望每次我们为该用户重建模型时都会发送的电子邮件，但是当我们重播第十个 PurchaseMadeEvent

We clearly don't want the email to be sent every time we rebuild the model for that user, but how do we stop this from happening when we replay our 10th PurchaseMadeEvent ?

推荐答案

事件链接非常棘手，很容易失控，所以我会尽量避免。例如，在您描述的情况下，我会提出一个 UserPromotedEvent （甚至使用 PromoteUserCommand ），我不会将电子邮件的实际/物理发送作为域的一部分。相反，我会为 UserPromotedEvent 创建其他处理程序/去规范化器，这很有可能会记录发送电子邮件的必要性和一些其他检查。之后，另一个过程将收集尚未处理的电子邮件的信息并将其发送。这种方法可以减轻在无法完全访问/可伸缩的电子邮件网关时可能出现的问题。

Events chaining can be very tricky and easily run out of control, so I'd avoid it as much as possible. For example in the scenario you're describing I'd raise a UserPromotedEvent (maybe even using the PromoteUserCommand), however I wouldn't consider actual/physical sending of an email as part of my domain. Instead I would create additional handler/denormalizer for UserPromotedEvent that would register the need of sending the email with some additional checks quite possibly. After that another process would gather information of not yet processed emails and send them. This approach would mitigate the problems that might occur with not fully accessible/scalable email gateway.

更笼统地说，事件链接的需要经常表明您应该考虑实施 Saga

In more general - the need of events chaining very often indicates that you should consider implementing a Saga for the process.

这篇关于事件来源：触发其他事件的事件&重建状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！