Restructuring EventSourcery

[stevehodgkiss]

Right now pieces of event sourcery feel very bundled together:

• EventSourcery::EventStore (Generic to the backing store) abstractions to handle polling an event store, event type serialization.
• EventSourcery::EventStore::(Memory|Postgres) backing store specific implementations
• EventSourcery::EventProcessing (generic EventStreamProcessor)
• EventSourcery::EventProcessing::(Memory|Postgres) implementations for Tracker, Projector, Reactor etc.
• EventSourcery::Command namespace - AggregateRoot, Repository, CommandHandler
• EventSourcery::Command is a generic command module that configures Virtus via an include, so by including that for a command object you actually get the above constants sitting below it :/

I am proposing to change this structure to be like this:

• EventSourcery::Postgres namespace for all postgres specific things. Once namespaced these can be easily extracted into a separate gem event_sourcery-postgres? Things like EventSourcery::Postgres::EventStore and EventSourcery::Postgres::(Tracker|Projector) etc would live here.
• EventSourcery::Memory namespace for all memory implementations. Could be split into a separate gem but probably not worth it given there's no extra dependency on an external lib.
• Move domain abstractions AggregateRoot, Repository to the top level (move EventSourcery::Command::AggregateRoot -> EventSourcery::AggregateRoot and the same with repository). The fact that AggregateRoot and Repository have lived under Command has bothered me for some time...
• Remove Command and Command::Handler, or move them to a separate gem. EventStore::CQRS? I don't think these should be part of the core event sourcery gem.
• Any necessary configuration for the specific pieces would live within that namespace (EventSourcery::Postgres.configure {|c| }` perhaps).

Any thoughts, objections or concerns at this stage? Not sure when I'll get to this but I'm keen to make these improvements.

[harukizaemon]

Like it. Like that EventSourcery is becoming more about the Event Streams. Would we then have a CQRSegregationary(tm)(pat.)?

I wonder if, like Command, AggregateRoot isn't really an EventSource term either and could thus move. My 2c worth: I think of Events as belonging to Streams and AggregateRoots are a mapping on top of those.

[stevehodgkiss]

@harukizaemon yeah I agree, event sourcing can be used without DDD so it would be better to not use those terms in the EventStore aspect of EventSourcery (e.g. use stream_id over aggregate_id in events table etc).

[grassdog]

Makes sense to me. Most event sourcing libraries I've seen use the term stream for what we call an aggregate. That's something we could move towards as well once things are more separated.

[mjward]

Makes sense to me 👍

I'd like to try and minimize these sorts of sweeping changes if we can help it going forward though (now that finance manages 3 x event sourcery apps). If this is something we want to do, we should def do it before open sourcing it 😄

[twe4ked]

Sounds good :+1:

[vonconrad]

EventSourcery::Postgres EventSourcery::Memory

👍 given the intent of this restructure.

Move domain abstractions AggregateRoot, Repository to the top level

If the goal is to decouple the event sourced aspects from the CQRS and DDD aspects, then these make no sense in the EventSourcery gem at all.

Perhaps a (yet another) separate gem?

Remove Command and Command::Handler, or move them to a separate gem. EventStore::CQRS?

I don't think EventStore::CQRS makes sense. What does CQRS have to do with an EventStore? Where does that top level namespace even come from? 😆

If we want separation, I prefer @harukizaemon's suggestion to make it something completely different e.g. CQRSegregationary (name pending). As a user, I'd like to be able to use EventSourcery with or without CQRSegregationary, but I'd also like to be able to use CQRSegregationary without EventSourcery. The CQRS pattern is useful outside of event sourcing as well.

If we still want to make the CQRS and DDD aspects somewhat related to "EventSourcery," I can buy EventSourcery::CQRS and EventSourcery::Aggregates as sub-gems. The former would house the Command/Query handling and the latter would be aggregates and repositories.