Hacker News Reader

Comment by ZenPsycho | Hacker News Reader

Something confusing I find in the example of a "reactor" here. The example causes a side effect "Send email" and another creates an event. Is the idea here that you're supposed to completely cut out "reactors" when you play back events? because, with these two examples, you'd shoot off a stale email, and then create a duplicate "showed promo" event that goes... exactly where when you're replaying?

It almost seems like it's obvious to just cut out reactors when you're replaying, but what if you introduce an almost invisible dependency on a reactor's results that makes the playback of application state NON deterministic? The old joke "then just don't do that" comes to mind, but it would be a bit nicer if the rules about what's allowed to do what, and more detail on what to avoid should probably be spelled out here?

It almost seems like allowing reactors to generate new events is a mistake! how do you keep that from becoming unmanageable mess?

View on HN

I think I understand your problem. When applying an event, how do you know whether it’s an event that just happened now, or something you’re playing back from months ago?

One solution I implemented was to log all of the ‘reactions’. Then when reacting, I checked whether the reaction had already happened to prevent side effects. For example:

    if !reactionLog.happened(reaction)
        sendEmail()
        reactionLog.log(reaction)

Admittedly, this was a system used by only 200 people and performance wasn’t too much of a concern. Also, if ‘sendEmail()’ has side effects, they won’t happen.

We used to differentiate between projections and event handlers

Projections only create/update/delete views and are idempotent.

Event handlers could do side effecty things like emails or generate another command that goes back into the system.

While playing back events, just didn't hook up the event handlers at all.

Worked beautifully and it was very liberating to be able to wipe out your entire read side and recreate it either exactly the same way or tweak it to handle evolving requirements.

Presumably, for this to work “event handlers” must not modify views, though they could also produce events (reflecting the fact of completion of their own side effects, if that needs to be noted) of their own that could drive projections or other event handlers.

I deal with it in the following way: External calls are only triggered on Commands, never on events.

In order to achieve this, I use process manager.

Say the event "User Signed Up" is dispatched. A process manager will then execute the "Send Welcome Email", the aggregate checks if the user aggregate root is in a state where a welcome email should be sent (something like a flag `welome_email_sent`). Depending on the result of your email provider, the event "WelcomeEmailSuccessfullySent" or "WelcomeEmailNotSent".

It is possible to react to the erroneous event with another process manager and retry.

Reply on news.ycombinator.com