The unified event dispatcher [messenger + event-dispatcher]

[takeoto]

Hello!

I'm trying to make my service layer more clear and pretty looking. To do this, I want to make my code more indifferent to its neighbors.

Something like this:

<?php

declare(strict_types=1);

namespace HomeSweetHome;

use Psr\EventDispatcher\EventDispatcherInterface;

/**
 * @serviceSays I don't care who uses me.
 */
class Service
{
    public function __construct(
        private readonly EventDispatcherInterface $eventDispatcher,
        # some "we don't care" dependencies
        # ...
    ) {
    }

    /**
     * @methodSays I don't care who calls me.
     */
    public function method(mixed ...$params): mixed
    {
        /**
         * @methodSays
         * I don't care:
         * - who will listen it;
         * - how it will be delivered.
         */
        $this->eventDispatcher->dispatch(new Event('some data'));

        return 'some a result';
    }
}

/**
 * @listenerSays
 * I don't care:
 * - who sends me events;
 * - how they are delivered.
 */
class Listener0
{
    public function __invoke(Event $event): void
    {
        # Some **light work** that needs to be done immediately.
        # Obviously, this should happen **synchronously**.
    }
}

/**
 * @listenerSays
 * I don't care:
 * - who sends me events;
 * - how they are delivered.
 */
class Listener1
{
    public function __invoke(Event $event): void
    {
        # Some **heavy work**, that can be done later.
        # Obviously, this should happen **Asynchronously**.
    }
}

/**
 * @eventSays I don't care at all.
 */
class Event
{
    public function __construct(public readonly string $param)
    {
    }
}

#region TLDR

Symfony gives 2 tools for managening events :

• the event-dispatcher (a native/default tool);
• the Messenger component (a more advanced tool).

Synchronous events/messages can be handled by both of them. I know that the Messenger component has more advanced logic, like middleware - which can be turned off and leave only a sender/receiver logic, but in general, it can do the same job, as the event-dispatcher.

After I installed the Messenger component, I was a bit confused, now I don’t need event-dispatcher, because I have a similar tool.

From my perspective, it’s better to use “service layer” interfaces or PSR interfaces in dependencies instead of some framework stuff. Symfony makes it possible to use the PSR interface for event-dispatcher and that's pretty cool, but I can't:

• use it for async events;
• overwrite the PSR event dispatcher interface with the Messenger bus class, since many parts of the framework use it (and dynamically add listeners to it).

Of course, I could:

• pass my event-dispatcher that implements the PSR interface and contains the Messenger bus call logic, but that's inconvenient because I have to either insert it manually in my services or bind my custom dispatcher in the “services > _defaults > bind” config with some unique variable name - from my point of view, this is very strange;
• send events using the native event-dispatcher and then redirect them in the listener to the Messenger bus - too many steps for nothing.

I really like the approach that the Messenger component provides, which gives me the tools to manage all the routes (flows) of my events and leaves handlers (with no php attributes to configure) with events in the "I don't care" state.

I'm thinking about merging event-dispatcher and the Messenger bus and using the nice PSR interface in my service layer. This can be done by completely replacing the default/native event-dispatcher with an additional bus (with a basic middleware) of the Messenger component for synchronous native events and logic for choosing which messenger bus should be used for which events.

Yes, it seems very scary, but as a result, I will look at my code in a "My precious" way.

If you have your own vision, please write it in the comments.

P.S. Who has read this - have a good day and a bigger salary.