DDD - Как изменить несколько AR (из разных ограниченных контекстов) в течение одного запроса?

Question

Я бы хотел раскрыть небольшой сценарий, который все еще находится в бумажной форме и который, в отношении принципа DDD, кажется немного утомительным.

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

Теперь давайте представим, что я хочу предоставить пользовательскому интерфейсу HTML-форму, которая составляет один набор полей для каждого ограниченного контекста, например, для обновления ограничений и / или функций. Как мне точно выполнить процесс обновления всех AR, не нарушая принцип одной транзакции на запрос? Могу ли я создать своего рода «внешнюю» AR, скажем, AR ClientHostingProperties, которая будет содержать ссылки на другие AR и обновлять их как часть отдельной транзакции, используя собственный репозиторий? Или мне лучше создать AR, который будет отправлять сообщения, на которые будут реагировать слушатели, предоставляемые ограниченным контекстом, и в этом случае мне, вероятно, следует подумать о ES?

Спасибо.

Answer 1

Краткий ответ: нет.

Агрегат - это граница транзакции, что означает, что если вы обновите несколько агрегатов за одно «действие», вам придется использовать несколько транзакций. Причина, по которой агрегат эквивалентен одной транзакции, заключается в том, что это позволяет гарантировать согласованность.

Это означает, что у вас есть два варианта:

1. Вы можете увеличить свою совокупность. Тогда вы на самом деле можете гарантировать согласованность, но ваша способность обрабатывать параллельные запросы ухудшается. Так что обычно это то, чего вы хотите избежать.
2. Вы можете жить с фактом, что это две транзакции, что означает, что вы в конечном итоге будете последовательны. Если это так, вы обычно используете что-то, например, диспетчер процессов или поток, для обработки обновления нескольких агрегатов. В своей простейшей форме поток - это не что иное, как простой , если это событие произойдет, выполните команду rule. В более сложной форме он имеет свое собственное состояние.

Надеюсь, это поможет 101

Answer 2

Как мне точно выполнить процесс обновления всех AR, не нарушая принцип одной транзакции на запрос?

Возможно, вы ищете менеджер процессов .

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

Это дает вам возможность отслеживать, была ли эта задача «выполнена»: вы сравниваете изменения в задаче с состоянием системы и запускаете команды (для запуска в изолированных транзакциях) для внесения изменений. .

Процессы, на мой взгляд, очень похожи на конечные автоматы. Эти задачи - команды выполнены, эти команды не выполнены, эти команды потерпели неудачу: что теперь? и в конечном итоге достичь состояния, в котором нет никаких дополнительных изменений, которые необходимо внести, и этот экземпляр процесса «выполнен».