Правило, которое я всегда применяю, состоит в том, что Aggregate должен быть чистым, без каких-либо зависимостей от служб, которые выполняют вызовы ввода-вывода (например, диск или сеть).Он должен давать один и тот же результат каждый раз, когда выполняет команду в заданном состоянии.Внедрение службы или передача ее в качестве аргумента в вызове метода нарушает это правило.Абстрактная идея состоит в том, что Агрегат никогда не должен принимать решение на основе данных, которыми он не владеет.
Однако каждая сложная система содержит больше, чем Агрегаты.Он также содержит менеджеров Sagas / Process (теперь только Saga), которые моделируют бизнес-процессы.Все, что нужно для разработки идеальной Saga, - это четкий бизнес-процесс и идемпотентные конечные точки.
Saga запускается, а затем прослушивает изменения в домене, обычно подписываясь на события домена.Он реагирует на них, посылая команды в соответствующую конечную точку.Обратите внимание, что я использую термин «конечная точка» для обозначения любого получателя, который обрабатывает команды идемпотентным способом.Агрегаты, будучи чистыми, являются такими конечными точками.Но конечной точкой Saga может быть также внешняя система, такая как платежный шлюз.Такой шлюз не должен инициировать новый платеж с существующим PaymentID (непрозрачным полем, которое отправляет ваша система).
Вывод : из того, что я вижу, все ваши сценарии могут бытьреализован как Sagas.
Вы можете прочитать больше о Sagas здесь и здесь и здесь .