0.5.1 Bugfix Release

Fixed

• Removed ContextProvider type hint to allow custom context providers called by a Flavour

0.5.0 Dev Release

Added

Support service injection into aggregate functions

In Event Machine and in Event Engine prior to this release it was only possible to inject a context object into aggregate functions using a context provider. Event Engine emphasise the usage of a functional core, which basically means: avoid side effects in aggregate functions. However, using dependencies in aggregate functions that fetch data from a database or remote service is not always a bad idea. Maybe fetching data is only needed if the aggregate has a certain state or you simply want to express data fetching as part of the business logic and record an event if it fails. Whatever reason you have, injecting one or more services into aggregate functions is now as easy as using a context provider:

private static function describeConnectWithFriend(EventEngine $eventEngine): void
    {
        $eventEngine->process(Command::CONNECT_WITH_FRIEND)
            ->withExisting(Aggregate::USER)
            ->provideService(GetUserResolver::class) // <-- Service id should be known by DI Container
            ->provideService(MessageFactory::class) // <-- order of provideService() calls determines order of handle function arguments
            ->handle(function (UserState $user, Message $connectWithFriend, GetUserResolver $resolver, MessageFactory $messageFactory): \Generator
            {
                $friendId = $connectWithFriend->get(CacheableUserDescription::FRIEND);
                //Check that friend exists using a resolver dependency
                $friend = $resolver->resolve($messageFactory->createMessageFromArray(Query::GET_USER, [
                    'payload' => [CacheableUserDescription::IDENTIFIER => $friendId]
                ]));
                yield [Event::FRIEND_CONNECTED, [
                    CacheableUserDescription::IDENTIFIER => $user->userId,
                    CacheableUserDescription::FRIEND => $friend[CacheableUserDescription::IDENTIFIER],
                ]];
            })
            ->recordThat(Event::FRIEND_CONNECTED)
            ->apply(function (UserState $user, Message $friendConnected): UserState
            {
                $user->friends[] = $friendConnected->get(CacheableUserDescription::FRIEND);
                return $user;
            });
    }

See the full example (and more) here: https://github.com/event-engine/php-engine/blob/master/examples/PrototypingFlavour/Aggregate/UserDescription.php

It's also possible to combine a context provider and services. In that case the context object is injected first, followed by the services. This behavior ensures, that existing aggregate functions with contexts continue to work.

Minor BC Break

As stated above: existing aggregate functions that use a context object continue to work. But to support the new feature a small change in the Flavour interface was needed: 98ad903#diff-00eabf99719cb7185f5cb7f2de7d52e4

If you use a custom Flavour or the OopFlavour and therefor your own OopPort, you have to adjust it. See changes in the examples: 98ad903#diff-dd975e16429f155208da76975871669b

0.4.0 Dev Release

Added

• #5 Add support to load aggregate state until version
  • This includes a small BC Break for the event store interface, see event-engine/php-event-store#1

0.3.2 Bugfix Release

Fixed

• added missing EventEngine::env() and EventEngine::debugMode() methods

0.3.1 Bugfix Release

Fixed: Parse error in ProjectionInfo

0.3.0 Dev Release

Support document store named indices

Minor BC Break: DocumentStore interface has 3 new methods to check,add and drop named indices on collections

0.2.0 Dev Release Mono-Repo Split

This release marks the second milestone towards a stable Event Engine release.
All namespaces previously defined in the php-engine mono-repo are now moved to their own packages.

Please find a complete list of all new packages here

0.1.1 Bugfix Release

v0.1.1

v0.1.1

0.1 Dev Release

0.1 Dev Release

Event Engine supersedes Event Machine

It will become a new major version taking all the great ideas of Event Machine and add many new features on top.

The namespace change is required due to naming conflicts with existing projects. We were able to register event-engine.io which will become the new home for the online documentation and some more stuff.

Version 0.1 marks an important milestone. All concepts of Event Machine have been ported to Event Engine and we've added many new features. We don't expect bigger breaking changes from now on. Event Engine is already used in a project, so we were able to test and verify the new features in the real world and not only in pet projects!

One of the goals for a new major release was to remove usage of prooph/event-sourcing and prooph/service-bus. Read more about it here
This work is completed. Event Engine takes over message routing as it holds the config for it anyway. The event sourcing mechanism is now based on a custom implementation, specifically designed to support the ideas behind Event Engine.

We tried to support the public API of Event Machine in Event Engine as much as possible. However, some changes are not compatible with Event Engine and require a migration. If you need a migration guide please ping us! Event Machine had no stable release (v1.0 of Event Machine is released at the same time as v0.1 of Event Engine). We plan to provide a list of changes and of course a list of all new features. However, a detailed migration instruction is not planed due to missing time!

What's Next

We're heading towards Event Engine v1.0, but there is still a lot of work ahead.

Repo Split

To ease initial development of new features and the new Event Engine core, we've put all code in the event-engine/php-engine repo. If you look at it you'll recognize that it uses multiple namespaces. Each namespace will be moved to its own repository on github, except the Event Engine core. That said, while it's enough to require event-engine/php-engine: v0.1 today, you'll need to require more packages in the future. A skeleton application similar to the current Event Machine Skeleton will provide a default set of packages for fast project ramp up.

More Detailed Tests

Once the repo is split, we'll release a v0.2 of all packages and start to add tests to each. At the moment main functionality of Event Engine is tested with high level integration tests, but don't expect a fully stable system. We make heavy use of EE in a project, but we don't use all new features yet and also use a custom Flavour for the project because we've migrated an existing code base from prooph v6 to EE.

Documentation

Documentation of Event Machine was never completed. The tutorial covered everything to get started and we definitely plan to provide a similar one for Event Engine. However, this time an incomplete documentation is considered as a blocker for a stable v1.0 release. While still being very beginner friendly, Event Engine is grown into a very flexible framework suitable for all kinds of projects. This requires comprehensive documentation so that everybody can use the full power of Event Engine.