Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
$eventEngine->process(Command::REGISTER_USER)->provideService(MyEmailAddressLookupService::class)->handle(....)MyEmailAddressLookupService::class is loaded from the DI container and passed as an argument to the aggregate function.
EmailAddressLookupService needs to perform read I/O (especially query a database for existing email address). Such operations should be avoided in a functional core and be handled in the application layer instead. Therefor you can also use a ContextProvider instead of a service. See the docsA context provider is invoked by Event Engine before a command is passed to an aggregate. Whatever is returned by the context provider (should be some kind of immutable state) is passed as an argument to the aggregate function. This way read I/O happens outside of the domain layer (the functional core)
thx @netiul
Unfortunately, the docs are not complete and lack a lot of details. The reason is, that we never defined a clear scope for Event Engine.
1) It started as a workshop framework to hide a lot of implementation details and provide a very descriptive interface instead so that people can learn CQRS/ES step by step.
2) Then it somehow turned into our company framework because we recognized that speed of development increases a lot with Event Engine.
3) Then we started to think about an Event Engine platform meaning that even the infrastructure is abstracted away (and managed by us)
4) In the early days of planning the platform we had the idea to take the abstractions one level higher and combine them with ideas from Event Storming and Event Modeling. So basically we asked us the question if it would be possible to generate code from an event map that is executed by Event Engine.
5) And that's the experiment we are running now. We're almost ready to share it with you guys. If you look into into the Event Engine org on Github: https://github.com/event-engine you'll notice many new code generator related packages. We're currently organizing our internal prototypes into open source libraries that can be used together with our tool InspectIO to run remote Event Storming sessions and generate source code without even leaving the tool.
6) A question I cannot answer yet is, how our results will effect the future of Event Engine? IMO visual modeling combined with a code generator is extremely powerful . Even more powerful than Event Engine. Because you move the abstractions out of the code to a visual level. The code itself can be more basic and can be optimized for other characteristics. Something we need to try and experiment with. And I hope we can do it all together next year, once we published the open source stuff and provided some guidelines how to use it.
AggregateRepository?
In fact, we recommend not using any framework or library as part of your domain model, and building the few lines of code needed to implement a left fold yourself - partly to ensure understanding and partly to keep your domain model dependency-free.
event-sourcing package before. When the code is properly designed, often it is already customizable.I would also add that it is a bit of a stretch to say implementing an interface that exposes events from your aggregate is not keeping your model dependency-free. Regardless of frameworks, you will always need to do something like that in one way or another. There will always be a dependency on something, and if you wrote that dependency or not, is not that relevant.
I have been working with the Axon Framework on kotlin for a while, and the approach is usually using annotations (not a big fan). I have to say I miss a lot the approach Prooph has/had.
I think apart from the additional maintainer effort, getting those "blueprints" and transforming them into a library would not hurt anyone.
5 replies
Prooph\EventStoreClient\Internal\EventStoreNodeConnection->__destruct()). I am having some trouble figuring out why no events are being persisted with supposed to be valid configuration (tested with telnet from the container). I noticed the same behavior when replacing the host/port with random characters. I registered listeners to onConnected, onErrorOccurred, onAuthenticationFailed, onClosed and the only one that outputs to logs is onClosed, but the message is Connection close requested by client (__destruct()). I am also passing settings enableVerboseLogging on createFromEndPoint with no apparent difference. Any ideas?
Loop::run wrapping everything (There are no impl for Prooph\EventStore\EventStoreConnection). Then the Loop::defer that initializes the TcpPackageConnection was not running.
