Паттерн Aggregate Outside

Рассматривается проблема протекания бизнес-логики из агрегата в случае, когда эта логика зависит от данных, находящихся за пределами агрегата. Здесь предлагаются несколько решений для данной проблемы, но каждое из них имеет свои недостатки.

Приведен пример вымышленного кейса, связанного с сервисом обмена валют. В этом кейсе агрегат представляет заявку на обмен валюты (Bid), и для выполнения его бизнес-правил требуются данные, находящиеся вне агрегата. Рассмотрены следующие бизнес-правила:

🟠Пользователь не может обменять более 1000 долларов в сутки.
🟠Если сумма обмена менее 100 долларов, курс берется из банка A, иначе из банка Б.
🟠Лимит и минимальная сумма могут изменяться в зависимости от дня недели.

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

🔴Агрегат имеет несколько внешних зависимостей, что увеличивает его сложность.
🔴Изменения в интерфейсах этих зависимостей могут потребовать изменений внутренней логики агрегата.
🔴Для тестирования агрегата необходимо создавать моки для всех зависимостей и фикстуры для всех данных, которые они возвращают.

Поэтому предлагается альтернативный подход, основанный на понятии «внешнего интерфейса» (outside interface). Вместо внедрения всех зависимостей напрямую в агрегат, они внедряются в отдельный враппер, который предоставляет данные в формате, удобном для агрегата. Это упрощает код агрегата и уменьшает его зависимость от внешних сервисов. Кроме того, разработку можно разделить на этапы: сначала реализуется бизнес-логика, затем подключается агрегат к инфраструктуре через внешний интерфейс, и в конце реализуется инфраструктура.

Такой подход позволяет разделить доменную логику от инфраструктурных аспектов, уменьшить зависимости агрегата и упростить его тестирование.