prolic on v1.10.3
prolic on master
update changelog (compare)
prolic on master
fix restarting projection durin… respect lock in memory resetting projection and 12 more (compare)
I would like to ask, about difference in implementation between PdoEventStoreProjector (https://github.com/prooph/pdo-event-store/blob/master/src/Projection/PdoEventStoreProjector.php#L332) and PdoEventStoreReadModelProjector (https://github.com/prooph/pdo-event-store/blob/master/src/Projection/PdoEventStoreReadModelProjector.php).
Is there a reason, why ReadModelProjector does not provide emit and linkTo methods?
hey @lunetics welcome back!
Regarding fragmentation of the tools. It is related to responsibilities:
prooph components (mainly event store v7 and v8 at the moment) is maintained by prooph OS core contributors
InspectIO, Cody (Code Generator) and everything related to Event Engine is developed and maintained by my company prooph software GmbH
So I have a double role: CEO of prooph software and core contributor of prooph OS
I'm willing to support a revival of prooph event-sourcing, if it would be based on InspectIO + Cody. Here is the open discussion: prooph/event-sourcing#90
Anyway, you can play around with InspectIO any time. The coding bot tutorial contains a link to a free version of it. We're working hard on documenting the advanced use cases like complete Value Object code generation or adding new methods to existing aggregates with a PHP AST based code generator. @sandrokeil can answer questions about it. He worked hard on it.
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:
For one of our clients we integrated parts from Event Engine in their internal company framework. Parts are:
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
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 ....
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.