Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
Event Engine has its own simplified event store interface so that event store http client could be used, but then the multi-document-store could not be used ...
If you want to use event store http client, Event Engine is not the best choice.
i guess you need to get used to it somewhat
Yeah, absolutely. It is highly opinionated, but also fully customizable thanks to Event Engine Flavours. I can only say that once you get used to it, Event Engine makes a lot of fun and saves huge amount of time. But it is our company framework so we designed it to fit our needs best, which are:
- fast MVP development
- provide good balance between eventual consistency, coupling and performance
- easy way to switch from strong consistency to eventual consistency on a case by case basis (iterative design, incremental improvements)
- out-of-the-box documentation (Event Engine Descriptions, InspectIO Code Gen, ...)
For one of our clients we integrated parts from Event Engine in their internal company framework. Parts are:
- Multi-Model-Store behind aggregate repositories
- Splitting of Aggregates into: behavior and immutable state
- Immutable value objects with event-engine/data
+ - prooph es v7 used as Event Store per context and also as a shared event store to exchange events between different contexts
- prooph projections
- prooph/common messages
Currently integrating InspectIO Cody into their stack. They are using InspectIO since a year now (> 70 people). It definitely changed the way how teams coordinate their work and collaborate x-team. really powerful toolbox if you want to go fully EDA
@lunetics @netiul
so far we did not run into trouble. Event Engine suggests to use immutable state for messages, as well as aggregate state and of course all value objects.
This combined with JSON Schema gives you strict types at runtime. If your structure evolves (be it an event or aggregate), you can pick one of the common strategies to get the change into your system:
1) Add nullable properties to existing structure: https://event-engine.io/api/immutable_state.html#3-4-5-2
2) Initialize new properties with a default: https://event-engine.io/api/immutable_state.html#3-4-5-4
3) Introduce a new event or use schema versioning (version in event name for example)
4) perform a stream-to-stream projection and change events from old to new
5) Rebuild aggregate state according to new structure
6) Introduce new aggregate and support old one only as long as existing instances are "closed"
7) Use upcasting
...
I think meanwhile we used each of those strategies at some point. In InspectIO for example we had to refactor a couple of aggregates and event flows because we introduced "Organizations" as a new structural layer. We had to refactor Team-Aggregate, Board-Aggregate, the way how one can share a board, invite members to a team and so on. Organization admins can now access all boards and teams of an organization, can invite guests, turn them into members, ....
That change was really tricky. We worked on it couple of weeks, started with Big Picture Event Storming and iterated on the solution with multiple design level stormings and implementation sprints. At the end I just deployed the new feature and activated it for our pro users without any issue. Most of them did not even notice that something had changed ....
Regarding aggregates:
you split up the aggregate behaviour AND the state
Exactly. Even the OOP Flavour of Event Engine uses this approach, with the difference that state is part of the aggregate, but is THE ONLY property and THE ONLY mutable part of the aggregate. This design is inspired by FP and for example Vaughn Vernon suggests a similar design in his vlingo/platform
It underlines the functional nature of event sourcing and moves you further away from traditional Entity-ORM style.
Especially in combination with the Multi-Model-Store you can safely reuse aggregate state for queries, because it is immutable. You can pass it around and use it insight other aggregates because immutability ensures that you cannot change that state outside of aggregate behavior and without recording an event.
thank you @fritz-gerneth :beers:
2 replies
Hello everyone :)
I am happy to announce, that Ecotone Framework now officially support Prooph's Event Store.
Documentation can be found here: https://docs.ecotone.tech/modelling/event-sourcing
Example Application here: https://github.com/ecotoneframework/php-ddd-cqrs-event-sourcing-ecotone
@prolic Thank you too for building such a complete, production-ready solution :)
I see great opportunities in this integration. I am going to expand that, as there is much more to integrate that current version has.
There is long road or that's even impossible to bring a copy of this solution as it require enormous amount of knowledge.
Neither Event Store can't be copied, neither Ecotone as those are years of tries and fails.
This is the time to shake PHP Community a little bit, showing new or already existing possibilities, making them easy to introduce in green and brown fields. :)
prooph/snapshotter#36
prooph/service-bus#194
prooph/event-store-bus-bridge#43
