Применение проверки/инвариантов в приложении CQRS

У вас есть бизнес-процесс, который охватывает несколько агрегатов, это точно. Для этого у вас есть два варианта:

1. Измените границу агрегатов, объединив несколько типов агрегатов в один. Код проще, компенсации делаются БД автоматически по откатам. Масштабируемость не очень.

2. Используйте Saga для моделирования всего процесса. Вам необходимо отправить компенсирующие команды для каждого отказа. Это вариант, о котором я напишу в остальной части ответа.

В основном вам приходится выбирать между одной большой (глобальной) транзакцией и несколькими меньшими (локальными) транзакциями.

Saga должна содержать только логику координации, она не должна сама по себе обеспечивать соблюдение бизнес-правил. Подсказка о том, как это смоделировать, такова: когда вы добавляете новое бизнес-правило, касающееся процесса покупки рекламы, Сага не должна изменяться.

Бизнес-правила (инварианты) должны проверяться каждым Агрегатом, которому принадлежат данные, необходимые для проверки. Например:

Правило 1. Они могут указать количество товаров, которые они хотели бы купить, которое должно быть между минимальным и максимальным значением, разрешенным в объявлении — The Ad Aggregate.

Правило 2: они должны быть активными (поскольку участники могут быть забанены — The Buyer Aggregate

Правило 3. Объявление должно быть активным (объявления могут быть приостановлены) — ​​The Ad Aggregate

Правило 1 и 3 проверяются Ad::buyedBy($buyerId, $quantity), а Правило 2 проверяется Buyer::buyAd($buyerId, $quantity). Сага просто склеит эти вызовы методов. Как это сделать, зависит от вашей низкоуровневой архитектуры и требований к отказоустойчивости.

Предположим, вы будете использовать стиль, продвигаемый cqrs.nu, где агрегаты обрабатывают команды (у них есть такие методы, как handleXXX(XXX $command)), например я бы так и сделал, тогда ваши агрегаты и ваша сага будут выглядеть так:

class Ad
{
    function handleBuyAd(BuyAd $command)
    {
        if (!$this->active) {
            throw new \Exception("Ad not active");
        }
        if ($command->quantity < $this->minimum || $command->quantity > $this->maximum) {
            throw new \Exception("Too litle or too many");
        }

        yield new AdWasBuyed($this->id, $command->buyerId, $command->quantity);
    }

    function handleCancelAdBuy(CancelAdBuy $command)
    {
        yield new AdBuyinWasCancelled($this->id, $command->buyerId, $command->quantity);
    }
}

class Buyer
{
    function handleBuyerBuysAd(BuyerBuysAd $command)
    {
        if ($this->banned) {
            throw new \Exception("Buyer is banned");
        }

        yield new BuyerBuyedAd($command->transactionId, $this->id, $command->buyerId, $command->quantity);
    }
}

class BuyAdSaga
{
    /** @var CommandDispather  */
    private $commandDispatcher; //injected

    function start($transactionId, $adId, $buyerId, $quantity)
    {
        $this->commandDispatcher->dispatchCommand(new BuyAd($transactionId, $adId, $buyerId, $quantity));
    }

    function processAdWasBuyed(AdWasBuyed $event) //"process" means only once
    {
        try {
            $this->commandDispatcher->dispatchCommand(new BuyerBuysAd($event->transactionId, $event->adId, $event->buyerId, $event->quantity));
        } catch (\Exception $exception) {
            // this is a compensating command
            $this->commandDispatcher->dispatchCommand(new CancelAdBuy($event->transactionId, $event->adId, $event->buyerId, $event->quantity));
        }
    }
}

Команды содержат $transationId, используемый для идентификации процесса покупки рекламы. Его также можно рассматривать как тип идентификатора корреляции. Вы можете сбросить его.

Сага запускается методом start. Вы также можете сбросить его и считать, что сага началась, отправив первую команду в Ad Aggregate. Я сделал так, чтобы было более понятно, как начинается этот процесс.

Если команда BuyAd не удалась, компенсация не требуется, но если команда BuyerBuysAd не удалась, то компенсация выполняется путем отправки команды CancelAdBuy в Ad Aggregate.

Обратите внимание, что эта сага реагирует только на события, отправляя команды и ничего больше. Он не навязывает никаких бизнес-инвариантов, он просто координирует весь процесс.

Модель предметной области является авторитетом для своего собственного текущего состояния, а не для каких-либо других частей процесса.

Обычно есть две разные проверки. Первый — проверка сообщения; это ваш случай, сообщение о покупке. Имеются ли в нем все необходимые данные, имеют ли данные правильную форму и т. д. На этом этапе проверки сообщение рассматривается изолированно, во многом так же, как при проверке XML-документа.

Предполагая, что это командное сообщение, мы теперь передаем его модели предметной области для выполнения действий. Модель предметной области отвечает за бизнес-логику изменения модели в ответ на сообщение.

Таким образом, модель домена знает, активно ли объявление, имеет ли этот конкретный участник хорошую репутацию, разумно ли количество элементов. Таким образом, он должен решить, как он будет меняться. Может быть, это вообще не изменится - неявно отбрасывая сообщение. Возможно, это изменится, добавив сообщение в явный список отброшенных сообщений.

Я борюсь с тем, как и где проверить приведенные выше бизнес-правила, которые в данном случае охватывают несколько агрегатов.

Иногда это намек на то, что границы ваших агрегатов не совсем правильные; в других случаях это означает, что вы неправильно думаете о чтении.

Как правило, сообщение направляется агрегату, который будет (возможно) изменяться, и возможность доступа к другим данным модели, необходимым для обработки сообщения, передается агрегату в качестве аргументов.

Они могут указать количество предметов, которые они хотели бы купить, которое должно быть между минимальным и максимальным значением, разрешенным в объявлении.

Они должны быть активными (поскольку участники могут быть забанены).

Объявление должно быть активным (реклама может быть приостановлена).

Похоже, #1 и #3 можно решить, заставив Ad порождать новый BuyTransaction, что-то вроде здесь.

Что касается № 2, я никогда не видел, чтобы системы обеспечивали валидность пользователя посредством немедленной согласованности на уровне домена (т. е. проверяли, активен ли текущий пользователь в той же транзакции, что и та, в которой участвует корень агрегата Ad). Я бы делегировал это на уровень контроля доступа.