Читается ли handler of domain event хенделором CQRS pattern?

Question

[BonBon Slick]

CQRS у нас есть command / query, но что на счет ивентов?
Для команды или квери у нас есть юз кейс, а вот считается ли ивент юз кейсом ведь он лежит и принадлежит вообще другому слое, Domain? В то время как CQRS ето Application.

Так вот, условно я делаю handler который слушает Domain ивент UserRegistered, куда мне впихнуть етот хендлер? Все хендлеры это ES слой Infrastructure, но в тоже время это хендлер условной команды. Ведь различия между командой и ивентом минимальны. Несут минимум данных, говорят о событиях. Команда что должно произойти, ивент что уже произошло, оба диспачит ивент бас только разные интерфейсы и мидлваре.

Сейчас структура такая

Application -> CQRS -> Command / Query -> UseCase / Handler -> RegisterUser / RegsterUserHandler
Domain -> Entity -> Event -> UserRegisteredEvent
Infrastructure -> EventSourcing -> Bus -> Handlers -> UserRegisteredEventHandler / EmailVerifiedEventHandler ...

Тег симфони важен, потом что у нас есть как EventDispatcher так и EventBus, то есть 2 папки

Infrastructure -> EventSourcing -> EventDispatcher -> Listeners -> UserRegisteredListener
Infrastructure -> EventSourcing -> EventDispatcher -> Subscribers -> UserRegisteredSubscriber

Так что дополнительныая смыслова нагрузка для композиторов симфоний и дирижеров. Ведь EventDispatcher по моим соображением подходит исключительно и только для использования DomainEntityEvent, отличия от DomainEvent в том, что UserRegistered ивент всего домена, а UserPasswordUpdated это Entity. В первом нужна асинхронность, а во втором последовательность и синхронность что бы сохранить ивент в БД. Если у вас другие мысли на счет Bus vs EventDispatcher вот впрос на который так и...

В общем, ваше мнение, куда ложить Domain event handler который был диспачнут через ивент bus как и команды / квери?
Почему вы так считаете?

Answer 1

[Максим]

1.

Для команды или квери у нас есть юз кейс, а вот считается ли ивент юз кейсом ведь он лежит и принадлежит вообще другому слое, Domain? В то время как CQRS ето Application.

Event не может быть Use Case. Event - это то, что произошло, а Use Case – это то, что нужно сделать (сценарии использования).

2. Так вот, условно я делаю handler который слушает Domain ивент UserRegistered, куда мне впихнуть етот хендлер? Сюда.

Все хендлеры это ES слой Infrastructure, но в тоже время это хендлер условной команды.

Не верное утверждение. Infrastructure – это то, что идёт от фреймворка. Возьмите Фреймворк Slim и вы поймёте на сколько он пустой). Всё остальное можно абстрагировать в свои классы.

3. Структуру тоже можете посмотреть по ссылке выше.

Application
    Command
    Query

Domain
    Entity
        class Id
        interface UserRepository
    Service
        interface PasswordHasher
    interface Flusher

Infrastructure
    Entity
        class IdType
        class DoctrineUserRepository implements UserRepository
    Service
        class CryptPasswordHasher implements PasswordHasher
    class DoctrineFlusher implements Flusher

В своих проектах я опускаю эти 4 папки и делаю всё без Application, Domain и т. д. Если у вас с пониманием что есть что нет проблем - можно опустить. Такое горизонтальное разбиение на папки часто избыточно. Пример

4.

Тег симфони важен, потом что у нас есть как EventDispatcher так и EventBus, то есть 2 папки

Когда вы начинаете проектирование по DDD, то Фреймворк обычно опускается. Используется самый минимум, а всё остальное изолируется. При этом вам не запрещают использовать компоненты симфони или других фрейморконезависимых компонентов. Но если это бандл - далеко не уедете)

5.

В общем, ваше мнение, куда ложить Domain event handler который был диспачнут через ивент bus как и команды / квери?

См. П.1

Comments

[BonBon Slick]

Да, спасибо за образец, оказался полезным!
Я на папочки разбиваю, проще потом возвращаться к проекту. Т.к. ето пет, может пройти 6-12 месяцев без работы над ним. Я обычно работаю над ним пока нет офф работы.

[BonBon Slick]

А что скажет на такой случай?)

final class AuthenticateUserHandlerDomain implements ISubscriberCommandHandler, IDomainEventHandler {
    private MessageBusInterface                $eventBus;

    public function __construct(      
        MessageBusInterface $eventBus
    ) {      
        $this->eventBus        = $eventBus;
    }

    public static function getHandledMessages(): iterable {
        yield AuthenticateUser::class;

        // also handle this message on userRegistered
        yield UserRegistered::class => [
            'method' => 'userRegistered',
        ];

        yield EmailVerified::class => [
            'method' => 'emailVerified',
        ];
    }

одновременно слушатель нескольких ивентов и в то же время команда. Куда ее?)