Update Prooph/Common dependency version to ^3 about event-sourcing HOT 5 CLOSED

@mvriel Thanks for your request. We already scheduled the update but due to your request we changed the timeline a bit ;) and released a new beta version for prooph/event-sourcing. A v3.0 major release will be available soon. We just want to wait for prooph/event-store which needs some more tests and alignment of the docs. But most of the work is already done.

Let us know how symfony integration works. If you encounter any problems feel free to open an issue.

Best,
Alexander Miertsch

prooph software GmbH

from event-sourcing.

Hello @codeliner,

Thanks for your fast response! We have been trying out Prooph EventStore and EventSourcing the past few days and it looks like a promising package. Our biggest 'dissatisfaction' is that it is rather invasivein our Domain Model since we have to extend our Aggregate Roots and Events from a base class. We would have rather have had to implement an interface and accompanying traits.

As such we are now running an experiment whether we can adjust the EventSourcing package to fit that desire; no idea yet how it will pan out exactly :)

from event-sourcing.

Hi @mvriel,

We use prooph/event-sourcing for our own software, so for us the coupling is ok, but we are aware that the coupling can be a problem for others. DDD states that your model should not be coupled with the infrastructure (of course for very good reasons).

That is the reason why prooph/event-sourcing and prooph/event-store are two separate packages.
The EventStore is part of the infrastructure but EventSourcing needs to happen in the model. You can not use the same magic as with Doctrine for example. And more importantly it is not a compromise: EventSourcing IS part of the model because domain events are.

We are not using traits because that wouldn't change the coupling with the package but things like the AggregateRootDecorator wouldn't be possible.

prooph/event-sourcing provides a AggregateRoot base class that completely hides event sourcing related methods like popRecordedEvents or reconstituteFromHistory from the public API of the implementing AR and with the help of the decorator pattern we don't need to work with reflection to access the hidden methods (less objects, more performance).

But the coupling is the price you have to pay. However, prooph/event-sourcing is really a small package so you can also just copy & paste it (or fork it) to get rid of the coupling :-)

The AggregateTranslator interface shipped with prooph/event-store decouples the EventSourcing part from the EventStore. And with the help of repositories you get close to the Doctrine way of separating model and infrastructure.
Just implement your own translator for your own event sourced aggregate roots.

Hope it helps to make the right decision.

Best regards,
Alex

prooph software GmbH

from event-sourcing.

Hi @codeliner,

Thank you for your elaborate answer. You confirm that my interpretation of the source code is accurate and indeed we found that the recording of events are to be public if we don't want to use reflection or the decorator. As such we have chosen to make these public, this allows us to remove the inheritance tree.

A bigger challenge is the DomainEvent classes since we would prefer bare Value Objects for our Domain Events. We are currently investigating wrapping our own Domain Events in a DomainEvent class before it is sent to the Event Store and reconstitute it once it is returned from the EventStore.

Thank you for your efforts; despite that in this project we would like to do things differently this is only a matter of opinion and imo does not reflect on your library at all

from event-sourcing.

@mvriel

A bigger challenge is the DomainEvent classes since we would prefer bare Value Objects for our Domain Events. We are currently investigating wrapping our own Domain Events in a DomainEvent class before it is sent to the Event Store and reconstitute it once it is returned from the EventStore.

That is the way to go. The DomainEvent used by prooph/event-store is for us of course the root for our domain events but for you it should only be the "infrastructure version" of a domain event. Call it a persistence domain event required by the EventStore to do its job. You don't even need a wrapper you just need a serializer/desirializer for your own domain events (you would need that anyway) and pass the array version of your domain event to the Prooph\DomainEvent. You can also use the FQCN of your domain event as messageName for the Prooph\DomainEvent. It can simply act as a DTO for the EventStore. The serializer/desirializer can be attached as a listener to the various EventStore methods. All methods provide hook points to attach listeners before or after the method runs.

But you are right, it is not so easy to get it to work. prooph/event-store 5.x is not released yet. So we would have room for improvements. We never really tried to persist custom domain events tbh. So if you need an easier API of the ES to achieve the decoupling please let us know! Maybe we can work together on it and release a second beta of prooph/event-store 5.x.

from event-sourcing.