Какой метод реализации при подходе CQRS правильный?

Question

[Markusam]

Есть проект в котором пытаюсь внедрить подход CQRS(Command Query Responsibility Segregation) и есть в нем два модуля Order и Store. И например есть такой бизнес процесс как создание ордера. Что б его создать необходимо сперва у модуля Store проверить работает ли этот store, то есть проверить его рабочие часы и дневной лимит на продажу(модуль оперирует этими данными), если store работает мы создаем order. Я вижу тут два подхода к реализации:

1. Реализовать это в application слое, например controller сначала делает запрос(query) в модуль Store на проверку работает ли этот store. Если успех то затем создаем соответствующую command из модуля Order и которая попадет в соответствующий handler который создаст order
   
2. Реализовать все это в handlere который создает order. То есть с handlerа делается запрос в другой модуль, через api service, дальнейший алгоритм такой же как и в пункте выше. Просто принятие решения на создание и запрос в сторонний модуль переносится в handler который создает order.
   

Какой из способов предпочтительней и какой более правильный? Может есть другой способ?

Comments

[Виктор]

Есть проект и есть в нем два модуля Order и Store

с handlerа делается запрос в другой модуль, через api service

Для модуля - два отдельных сервиса? Не понятна текущая архитектура и что подразумевается под модулями.

[Markusam]

Виктор,
Архитектура монолит, модуль это набор логически связанных между собой классов в одном неймспейсе, то есть например для Order это его классы которые лежать в папке Order, различные его Value Object, вспомогательные сервис классы, repository и fetcher для Order, его Aggregate Root. За пределами своего неймспейса модуля, классы напрямую не используются и не вызываются, кроме Api service классов. Упрощенный пример такого Service для Store

Интерфейс

interface StoreApiServiceInterface
{
    public function retrieveActiveStore(DateTimeImmutable $currentTime): ?StoreDTO;
}

namespace App\Store\Application\Api;

И такая же упрощенная реализация

namespace App\Store\Application\Api;

use App\Store\Application\UseCase\Get\Active\GetActiveStoreQuery;
use App\Store\Application\UseCase\Get\Active\GetActiveStoreQueryHandler;
use App\Store\Domain\ReadModel\StoreReadModel;

final class StoreApiService implements StoreApiServiceInterface
{
    private GetActiveStoreQueryHandler $storeQueryHandler;

    public function __construct(GetActiveStoreQueryHandler $storeQueryHandler)
    {
        $this->storeQueryHandler = $storeQueryHandler;
    }

    public function retrieveActiveStore(DateTimeImmutable $currentTime): ?StoreDTO
    {
        $query = new GetActiveStoreQuery();
        $query->currentTime = $currentTime;
        
        $resultCollection = $this->storeQueryHandler->handle($query);
        if ($resultCollection->isEmpty()) {
            return null;
        }
       
        /** @var StoreReadModel $store */
        $store = $resultCollection->getFirstElement();

        return new StoreDTO(
            $store->id,
            $store->name,
        );
    }
}

Для модуля - два отдельных сервиса?

Для модуля который планируем вызывать из вне заводим подобные свои сервисы, то есть для модуля один такой сервис

Answer 1

[Виктор]

Архитектура монолит.
например для Order это его классы которые лежать в папке Order, его Aggregate Root

У Вас модуль = агрегат? Это не одно и то же.

За пределами своего неймспейса модуля, классы напрямую не используются и не вызываются, кроме Api service классов

Модуль - самостоятельная единица, которая должна работать без других модулей. Low coupling, high cohesion. Представьте, что он может подключаться через composer, вот каким он должен быть? У Вас так?
Что за паттерн "Api service", который какие-то DTO отдает? У агрегата может быть id другого агрегата и этого ему должно быть достаточно.

У Вас один контекст? Когда кто-то говорит "Store" (или, скорее всего, склад), все имеют ввиду одно и то же? Store с точки зрения покупателя и Store с точки зрения какого-то другого актора (например, поставщика) - одно и то же?
Если нет, Вам стоит разделить 2 контекста и сделать 2 Store. Один самостоятельный, и один как поддомен у Order и тогда вся логика будет в Order.

spoiler

слой Application одного контекста не может ссылаться на слой Domain другого контекста

Если контекст единый, может Store не заслуживает быть самостоятельным агрегатом? Если все-таки заслуживает, Order может выполнять свои обязанности, имея только id из Store? Это "на подумать".

В любом случае, один агрегат может воспользоваться другим (но не получать напрямую его объекты для реализации своей логики, только использовать функционал Aggregate Root), но если ими можно воспользоваться в слое Apprication последовательно - это будет лучше.

сперва у модуля Store проверить работает ли этот store, то есть проверить его рабочие часы и дневной лимит на продажу

Мне кажется, очевидно, что если это все-таки 2 разных агрегата одного контекста, то Store даже бизнес-логику тут не реализует, нужно просто проверить спецификацию. Делать это нужно в Application, вызвать 2 агрегата последовательно. Не нужно делать это ответственностью Order.

Comments

[Markusam]

Что за паттерн "Api service", который какие-то DTO отдает?

Ну это выходит anti corruption layer, так как он получает данные из одного контекста и превращает их в формат который может поддерживать другой контекст но я так понимаю это не желательно делать, а достаточно ограничится просто store id?

Делать это нужно в Application, вызвать 2 агрегата последовательно. Не нужно делать это ответственностью Order.

Если полностью перейти к практической реализации то правильно ли понимаю, в OrderHandler сначала выполняю проверяю спецификацию Store, если условие удовлетворено уже создаем Order?

[Виктор]

Ну это выходит anti corruption layer, так как он получает данные из одного контекста и превращает их в формат который может поддерживать другой контекст

А что, у вас есть несколько контекстов? Не вижу это в описании задачи. Или Вы не только модули к агрегатам приравняли, но и BoundedContext к ним? Предохранительнй слой в DDD, согласно книге, служит красивым фасадом чего-то не красивого. Если был бы возможен рафакторинг, API этого слоя стало бы API того слоя, фасадом которого он является.

Если полностью перейти к практической реализации то правильно ли понимаю, в OrderHandler сначала выполняю проверяю спецификацию Store, если условие удовлетворено уже создаем Order?

Да, это вариант для того случая, когда контекст один.
Правда я считаю, что OrderHandler - плохое название, сбивает с толку, ведь он не является частью агрегата Order. Надеюсь, у Вас более внятные названия обработчиков команд (например, CreateOrderFormStoreCommandHandler, но Вам виднее какая там на самом деле происходит команда).

[Markusam]

Вы не только модули к агрегатам приравняли, но и BoundedContext к ним?

Да, насколько понимаю это ошибка так как в одном context может быть n модулей?

[Виктор]

Markusam, да, контекст - это разный смысл одной, казалось бы, сущности. Т.е. "что-то" в зависимости от контекста.
У Вас может быть 2 склада, один будет в контексте "поставщики" и у него будет адрес, время работы, отдел по работе с бизнес клиентами и т.п., а другой будет в контексте "покупатели" и у него будет город, служба обратной связи для клиентов и т.п.
Не уверен, что склады стоит отделять в модули. В контексте есть слои, возможно достаточно расположить агрегаты в доменном слое, они уже будут изолированны от доменного слоя другого контекста. Но это уже Вам решать.

[Markusam]

Понял, спасибо