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)
MyEmailAddressLookupService::classis loaded from the DI container and passed as an argument to the aggregate function.
EmailAddressLookupServiceneeds 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
ContextProviderinstead of a service. See the docs
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.
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-sourcingpackage before. When the code is properly designed, often it is already customizable.
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
onClosedand the only one that outputs to logs is
onClosed, but the message is
Connection close requested by client(
__destruct()). I am also passing settings
createFromEndPointwith no apparent difference. Any ideas?
Loop::runwrapping everything (There are no impl for
Prooph\EventStore\EventStoreConnection). Then the
Loop::deferthat initializes the
TcpPackageConnectionwas not running.