Use EventMatcher when registering event handlers about eventhorizon

[grrtrr]

Thank you for sharing this. This idea seemed neat to me and so I had it copied in one of my projects.

After using it for a while, I ended up merging both handlers,

• it was more straightforward to do the event-filtering (EventMatcher) at the top of the EventHandler,
• it would return before any shared resources (locks) needed to be taken,
• having to maintain 2 functions per event greatly increased the amount of duplicate code.

Unless there are huge performance considerations (which I doubt, since go makes running many thousands of goroutines at the same time possible), I found it led to a simpler overall design.

[maxekman]

Glad it could help! I would love to hear more about your implementation, maybe you can show an example in a gist?

[grrtrr]

This is in magicbus,

• an event is a directed message (Source() -> Dest(), it is possible to make Source() optional);
• the EventHandler both
  • filters events by relevance and
  • processes them, as per above comment.

There are 2 ways to process events:

• for Aggregates, these are multiplexed with Commands (i.e. at most 1 Command or Event is being processed at any time), as per Actor "serialized code" principle;
• everything else (e.g. loggers, writers) can subscribe as Observer, which means immediate notification.

(Aggregates only get the events whose Dest() matches the AggregateID, and only if they implement the optional EventHandler interface).