event-engine/php-engine

PHP Event Engine

php-engine's Issues

Next Gen Event Engine

I'd like to start a discussion around next generation of Event Engine. I start with a summary of What, followed by details about the Why

What

Next version of Event Engine should be a collection of small libraries focused on different aspects of event-driven architecture, optimized for usage in cloud environments with a strong focus on serverless. Rapid Application Development will no longer be achieved by an engine implementation with descriptions and abstractions, but instead will make use of visual modeling in InspectIO and its code generation capabilities.

A project developed with Event Engine could look similar to a monorepo managed with Nx.dev. The monorepo is visualized and organized on an InspectIO Event Map with a connection to a Cody Server sitting in the root of the monorepo.

We will provide a skeleton for the monorepo, InspectIO Metadata Templates, various Cody hooks and also service templates/skeletons for different kinds of EDA services, like a command handling-, query-, projection- and process manager service.
Based on information received from InspectIO the Cody server can automatically install such services into the monorepo and generate all necessary boilerplate code. The services can then be deployed as serverless functions and use cloud infrastructure for storage, communication, etc.

Why

Event Engine was designed to enable Rapid Application Development with full-featured Event Sourcing. Event Engine Descriptions are optimized to reduce boilerplate code as much as possible and act as documentation/overview at the same time. This allows you to develop complex business logic nearly as fast as CRUD logic. But it also has its price. The public API of Event Engine is simple and easy to understand even for devs who never worked with this technology before. But under the hood Event Engine is a complicated beast. Event Engine Flavours offer a lot of customization options, but it is another layer on top of an already heavy layer.
With InspectIO now supporting code generation, we can move descriptions from source code to the Event Map and replace abstractions by code generation so that the generated source code is clean, simple and organized in a very thin layer which is the monorepo itself. This combined with well documented cloud infrastructure is a very powerful combination and should be our focus in the future.

New release please?

@codeliner could you create a new release with the latest changes?

Restore aggregate root in event engine

Hi,

I'm trying to restore my aggregate root in event engine. But I've got some thoughts about it (fyi I'm using the OOP flavour):

In the previous event-sourcing package of prooph, you could use a collection to restore your aggregate, but I think in event-engine, you need to restore it via the EventEngine class? Correct me if I'm wrong.

So, I inject the EventEngine class and can now use the loadAggregateState or the loadAggregateStateUntil functions to restore the aggregate state. Am I right if the first one is trying to restore the state via the documentstore, and if that is not possible, it tries to restore it via the events. The latter restores the state directly via events.

And now I can use the state as a parameter for the reconstituteFromStateArray method, so I retrieve the aggregate root. Case closed, I have my aggregate root.

But their are also two private methods loadAggregateRoot and loadAggregateRootUntil, but they are private methods. Wouldn't be nice if those methods were public, so we don't have to call the reconstituteFromStateArray?

Any roadmap?

Thanks for your work, as we see this engine will be the new version of the event-machine project?

We try to review the new updates every week, and hope if there is any roadmap or blog post to talk about the new updates?

Thanks in advance.

How does migration work?

Hi,

I was wondering, couldn't find it in the docs: how state/docStore migration works?
Let's say I add a new required property: how would you make sure, that the persisted states/models in the system will get updated as well?
Do you have a best practice/example somewhere?

Describe differences between original project and fork

Because this project has no usual github link ("frorked from ...") to original Event Machine repository (https://github.com/proophsoftware/event-machine) it's hard to understand a difference.

Can you add link to original project to your readme?

Method fromCachedConfig should only load config

The method fromCachedConfig should be split up. It should only load the config and after that, the initialize() method should be called like for the normal initialization. For instance if the $eventQueue parameter is an instance which relies on event engine itself it can only be created via proxy manager.

    public static function fromCachedConfig(
        array $config,
        Schema $schema,
        Flavour $flavour,
        EventStore $eventStore,
        LogEngine $logEngine,
        ContainerInterface $container,
        DocumentStore $documentStore = null,
        MessageProducer $eventQueue = null
    ): self {

Using the specification pattern in combination with Event Engine

Hi,

Previously I used the specification pattern in the prooph EventSorucing library. Their were no troubles because the state was immediately changed after the events were recorded (via the apply function):

 /**
     * Record an aggregate changed event
     */
    protected function recordThat(AggregateChanged $event): void
    {
        $this->version += 1;

        $this->recordedEvents[] = $event->withVersion($this->version);

        $this->apply($event);
    }

So i could send the aggregate root object to a specification and check if the state will met the condition.

In Event engine I used a context provider that will generate the specification, so the specification is send to the second parameter in my aggregate method.

But the problem is that the state is not updated in this method because the apply method is not called after that the events are recorded.

public function recordThat(DomainEvent $event) : void
    {
        $this->recordedEvents[] = $event;
    }

The state is only changed in the apply method, But is there a proper way of accessing my Specification object in the apply methods?

Or do I have to configure my oop port so I can send the specification object via the port?

Thx in advance!

Greetings,
Arne

meaning of CommandDispatchResult

Hi,

Thx again for this amazing library!

I was wondering why you should use the CommandDispatchResult? I searched it in the docs, but couldn't found it.

For example I've figured out that you could return a CommandDispatchResult in the controller if you just sending a command to a controller. Can you give me some examples in which situations you should/could use the CommandDispatchResult?

Thx in advance,

Greetings!

Check uniqueness of Command, Query and Event names

When adding commands, queries or events to the event engine, it is checked if the name that should be registered is already registered. That check only happens in the same "space", meaning I could potentially register a command and an event with the same name. In the Swagger file generation the uniqueness is also not checked, meaning one will overwrite the other. Took me quite a while to figure that out. An additional check would help here a lot.

Happy to provide a PR if this makes sense for you :)

Support dedicated dispatcher for commands

Event engine should dispatch commands to an dedicated dispatcher if defined like it does for the events with eventQueue. This allows to support async messages in a chain from listeners (event -> command (async)) for instance. At the moment the commands from a listener can not be evaluated because they are handled internally.

EventEngine::rebuildAggregateState does not work as expected with MultiModelStore

If a MultiModelStore is configured, rebuildAggregateState uses last document state for rebuild. It's a problem of \EventEngine\Aggregate\GenericAggregateRepository::getAggregateRoot.

The expected behavior is to replay all events. The document store state should not be considered.

Cannot rewind a generator that was already run

Hi,

Thx for the new event machine v2!

I was implementing the event engine tutorial (https://event-engine.io/tutorial/) but I'm stuck on an exception thrown in the postgresql event store: It throws 'Cannot rewind a generator that was already run': https://github.com/prooph/pdo-event-store/blob/master/src/PostgresEventStore.php#L194-L200

The error is thrown at line 200. But the problem is that the iterator (here the Generator) is looped in the prepareData function and rewinded in the \iterator_count function. And that throws the exception. See https://www.php.net/manual/en/generator.rewind.php

Is there a workaround for preventing this error?

Thx in advance,

Arne

Process manager in event-engine

Hello,

Is it possible to use some sort of process manager for the generated events?

Thx in advance,
Arne

Context Providers should also receive the state if exists

Same as for the callSubsequentAggregateFunction context provider should receive the $aggregateState when $this->createAggregate is false.

It's also not clear from the documentation, neither from the code what are the possible arguments for context providers, and aggregate handlers: this should be better communicated.