Change Event Store from decorators to middleware

[jaspernbrouwer]

I've been considering changing the decorator style of StoresEvents into middlewares. This would enable you to configure the middleware that records the messages after the actual Event Store (which will be a middleware itself). This feels more natural from the commit() point of view.

But viewing it from the read() side, any middleware that's configured after the actual Event Store can be seen as the starting-point (in stead of the end-point like with commit()). But there is no earlier point than the Event Store, that's where the events originate. So anything "before" that point doesn't make sense.

Then again, I don't really see a case where you would manipulate the events when reading them, so read() in any middleware would probably just be a simple pass-through.

I'd love some advise on this!

[jaspernbrouwer]

Maybe an example would illustrate the issue better:

Let's say we have a layer that enriches metadata, another that publishes events, or at least pass the event to something else to later be published, and one that commits/reads events to/from a db.

Using the decorator style, the flow would be:

commit: "enrich metadata" -> "publish events" -> "commit to db"
read:   "return result"   <- "return result"  <- "read from db"

While the read() side look fine, the commit() side is a bit awkward. It seems like the events are published before they are committed to a db. Even if "publish" events means they are collected only to be published when a transaction is complete, the order still feels unnatural.

Using the middleware style (changing the order a bit, because we can now), the flow would be:

commit: "enrich metadata" -> "commit to db" -> "publish events"
read:   "return result"   <- "read from db" <- "return result"

Now the commit() side does feel natural, commit to db first, then publish.
But the read() side looks off: The middleware that publishes events on commit, returns the result of "the next one" (there is no next one in this setup) on read. At that point there are no results to return.
And the middle one is the one that reads from db, so that's where the results start. It would (probably) ignore results it receives from the next one.

[jaspernbrouwer]

Maybe it's worth mentioning that in the way it's currently set up (decorator style), the the one that commits/reads to/from a db is an actual event-store, the other 2 are decorators.

Using the middleware style would negate that distinction; they're all middlewares.

[mvriel]

When talking DDD and layers you usually push upward:

Application Layer -> Domain Layer -> Infrastructure Layer

Viewed from this perspective the decoration method feels more logical to me as this I see a linear Domain Layer to Infrastructure Layer shift where the middleware version goes from Domain Layer to Infrastructure Layer back to Domain Layer.

In addition, given your description, it feels odd that the Read chain has a sort of NOOP action in it (the 'return result' that does not return anything) while in the decoration example each actually functions, albeit a bit duplicate perhaps.