Event sourcing: decouple from core#449
Conversation
packages/Ecotone/src/Modelling/Config/AggregateRepositoriesCompilerPass.php
Outdated
Show resolved
Hide resolved
packages/Ecotone/src/Modelling/AggregateFlow/AggregateRepository.php
Outdated
Show resolved
Hide resolved
|
|
||
| use Ecotone\Modelling\AggregateFlow\SaveAggregate\AggregateResolver\ResolvedAggregate; | ||
|
|
||
| interface AggregateRepository |
There was a problem hiding this comment.
What's the purpose of this interface?
And do you see it as user facing interface or more internal one, where state-stored and es-based will be kept on the userland level?
There was a problem hiding this comment.
This interface is meant to abstract StandardRepository and EventSourcedRepository to avoid any BC. One could directly implement AggregateRepository instead of StandardRepository or EventSourcedRepository.
AggregateRepository is a lower abstraction, owned by the core "Aggregate module".
The idea is that an Aggregate read and store some state (which can be standard or event sourced) and publish events.
EventSourcedRepository is a higher abstraction that makes it easier for another package to implement an event sourced repository. This interface would reside in Ecotone\EventSourcing package. Ecotone core event sourcing package would handle any EventSourcedRepository interface to build an AggregateRepository in Ecotone core.
Actual event sourcing Prooph implementation would then reside in its dedicated package, so another implementation could be easily installed into Ecotone.
I am not sure yet, but the projection logic would reside in core EventSourcing package. It would be able to project any events from an EventSourcedRepository and gap detection and stream position would be managed by Ecotone.
Does it makes sense ?
There was a problem hiding this comment.
I realize I did not really answer your question :) I think this interface is more internal as it exposes some low level blocks (ResolvedAggregate). But it may be used by package maintainers to implement new ways of storing aggregates.
There was a problem hiding this comment.
Oki. Having an another EventSourcedRepo on top of AggregateRepository (when we also have ES and State, which points to this) is a bit unclear to me, but happy to discuss it when the time will come.
But in general I do feel the vibes, so happy to approve when ready.
And having smaller PRs like this make it much easier to review and discuss, so thanks :)
Taken from RepositoryStorageTest
|
@dgafka , let me try to break |
|
@jlabedo oki, let me know when ready |
| use Ecotone\Modelling\BaseEventSourcingConfiguration; | ||
|
|
||
| #[ModuleAnnotation] | ||
| class EventSourcedRepositoryModule implements AnnotationModule |
There was a problem hiding this comment.
I guess we could move it to Ecotone\EventSourcing?
There was a problem hiding this comment.
Yes we could, but we still need to keep it in core_package list for ecotone lite testing to work now.
|
|
||
| public function getModuleExtensions(ServiceConfiguration $serviceConfiguration, array $serviceExtensions): array | ||
| { | ||
| $baseEventSourcingConfiguration = BaseEventSourcingConfiguration::withDefaults(); |
There was a problem hiding this comment.
I would add @TODO Ecotone 2.0 to move it EventSourcing package
2 participants
Why is this change proposed?
Decouple event sourcing from core Ecotone aggregate modeling.
The end goal is to push event sourcing related logic into its dedicated package
Ecotone\EventSourcingDescription of Changes
Refactoring.
Introduction of
AggregateRepositoryinterface which is implemented byEventSourcedRepositoryAdapterandStandardRepositoryAdapter.Pull Request Contribution Terms