Split EventStore*Connection interfaces about event-store-client HOT 6 CLOSED

@codeliner from your code example, I can't know which interface is implemented on which connection implementation here.

About PublishingConnection - I don't think it's a good idea to have an event store connection being responsible to publish events on the message bus.

The setup looks strange, what if I change the order, f.e. inject UpcastingConnection into SnapshotConnection instead the other way around? Will it break?

I think from an end user perspective it looks much easier to setup like this:

$repository = new AggregateRepository($connection, $upcaster, $snapshotter, $publisher);

or maybe this:

$plugins[] = $upcaster;
$plugins[] = $snapshotter;
$plugins[] = $publisher;
$repository = new AggregateRepository($connection, $plugins);

from event-store-client.

@prolic it is always the same interface. The real connection gets decorated by connection implementations that implement the same interface, add their specific functionality and then call the parent method.

You can of course change the order. It's like a middleware pipe.

But ok, if you don't like it we need to find another way. The thing is moving upcasters and metadata enricher to the aggregate repository is wrong IMHO. You would need to pass the same plugins to each repository and prooph/event-sourcing is not always used. It is a separate package. micro for example don't use it. So we would need to create another plugin system for micro :(

from event-store-client.

from event-store-client.

micro was just an example. Good that most parts are covered but does not change the main issue that the aggregate repository is not responsible for a full blown plugin system. the event store is the central component and should provide the hooks. SnapshotStore is the only exception because it provides aggregate snapshots. Upcaster, MetadataEnricher, Publisher all deal with the events written to or read from the event store no matter where they come from.

That was the original idea of the plugin system. Not a fan of changing this. Why can't the event-store-client have a plugin system?

from event-store-client.

So maybe wrap the event store with "something" that has plugins? Like the ActionEventEmitterEventStore wrapper from v7

from event-store-client.

yeah, that sounds good 👍

from event-store-client.