Руслан Гнатовский aka @Number55 в своей статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье, а также в комментариях, поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение, которое этих недостатков лишено.
В качестве примера возьмем выдуманный кейс, который чуть сложнее валидации электронного адреса пользователя на уникальность.
Предположим у нас есть сервис обмена валют. И есть агрегат заявка на обмен валют (Bid). У этой заявки есть следующие бизнес правила:
Пользователь не может обменять более 1000 долларов в сутки
Если сумма обмена менее 100 долларов обменный курс берется из банка A, если больше то из банка Б.
Лимит и минимальная сумма могут отличаться в зависимости от дня недели
Для упрощения примера предположим что мы всегда обмениваем доллары и курс у банков не меняется в течении дня.
Как видим для проверки бизнес требований нам нужны данные которые находятся за пределами агрегата Bid. Только вариант номер 2 в статье Руслана (внедрение репозитория в агрегат) позволяет сделать эти проверки внутри агрегата. Поскольку проверок несколько то кроме репозитория нам потребуется внедрить еще несколько зависимостей
Сам репозиторий с методом получения заявок пользователя на конкретный день:
<?php interface BidRepository { public function add(Bid $bid): void; public function get(Uuid $id): Bid; /** * @return Bid[] */ public function getUserBids(DateTimeImmutable $date, Uuid $userId): array; }
Сервис для коммуникации с банком.
<?php interface BankGateway { public function getExchangeRate(Currency $source, Currency $target): float; public function makeBid(Amount $amount, Currency $targetCurrency): void; }
Репозиторий для настроек для каждого дня недели
<?php final class ExchangeSettings { public function __construct( public int $dayOfTheWeek, public int $dailyExchangeLimit, public int $premiumLimit, public int $someOtherSettingNotRelatedToBid ) { } } interface ExchangeSettingsRepository { public function getExchangeSettings(int $dayOfTheWeek): ExchangeSettings; public function addExchangeSetting(ExchangeSettings $settings): void; }
Чтобы проверить все требования внутри агрегата, нам придется внедрить все эти зависимости, в итоге код будет выглядеть примерно так:
<?php final class Bid { private float $rate; public function __construct( private Uuid $id, private Uuid $userId, private DateTimeImmutable $createdAt, private Amount $amount, private Currency $targetCurrency, private BidRepository $bidRepository, private BankGateway $bankA, private BankGateway $bankB, private ExchangeSettingsRepository $exchangeSettingsRepository ) { $this->assertExchangeLimitDoesNotExceed(); if ($this->amount->getValue() > $this->exchangeSettingsRepository->getExchangeSettings((int)($this->createdAt)->format('N'))->premiumLimit) { $this->rate = $this->bankA->getExchangeRate($this->amount->getCurrency(), $this->targetCurrency); } else { $this->rate = $this->bankB->getExchangeRate($this->amount->getCurrency(), $this->targetCurrency); } } private function assertExchangeLimitDoesNotExceed(): void { $total = 0; foreach ($this->bidRepository->getUserBids($this->createdAt, $this->userId) as $bid) { $total += $bid->getAmount()->getValue(); if ($total > $this->exchangeSettingsRepository->getExchangeSettings( (int)$this->createdAt->format('N') )->dailyExchangeLimit) { throw new RuntimeException('Exchange limit exceeded!'); } } } public function getAmount(): Amount { return $this->amount; } }
Диграммма зависимостей будет выглядеть так:
На мой взгляд у такого подхода есть ряд проблем:
Агрегат имеет несколько внешних зависимостей, которые содержат методы с сайд эффектам которые он в теории может вызывать. Например вытащить из репозитория другой агрегат и изменить его состояние.
Изменения интерфейса этих зависимостей не контролируется агрегатом, и может потребовать изменения внутренней логики агрегата.
В момент реализации бизнес логики мы должны задумываться о деталях интерфейса внешних зависимостей которые напрямую не связаны с логикой агрегата.
Для того чтобы протестировать такой агрегат нам придется создавать мок для каждой из этих зависимостей и создавать фикстуры для всех данных которые они возвращают даже если агрегат не использует часть этих данных.
А что если мы попробуем плясать от потребностей агрегата, и на этапе реализации бизнес логики не будем задумываться о том откуда именно агрегат будет получать внешние данные. Для начала опишем потребности агрегата во внешних данных в виде интерфейса, который будет находится в слое Domain рядом с агрегатом:
<?php interface BidOutside { public function getStandardRate(Currency $sourceCurrency, Currency $targetCurrency): int; public function getPremiumRate(Currency $sourceCurrency, Currency $targetCurrency): int; public function getPremiumLimit(DateTimeImmutable $date): int; public function getDailyLimit(DateTimeImmutable $date, Uuid $userId): int; }
Реализация этого интерфейса размещенная в слое Infrastructure возьмет на себя всю работу по подготовке и конвертации данных из внешних источников в формат удобный для агрегата.
Т.е по факту вместо внедрения всех вышеперечисленных зависимостей напрямую в агрегат, мы их внедрям в некий враппер, который отсекает не нужн��е методы, получает данные из этих зависимостей и конвертирует их в формат удобный для агрегата.
Диграмма зависимостей будет теперь выглядеть так:
Благодаря этому код самого агрегата сильно упроститься:
<?php final class Bid { private float $rate; public function __construct( private BidOutside $outside, private Uuid $id, private DateTimeImmutable $createdAt, private Uuid $userId, private Amount $amount, private Currency $targetCurrency, ) { $this->assertExchangeLimitDoesNotExceed(); if ($this->amount->getValue() > $this->outside->getPremiumLimit($this->createdAt)) { $this->rate = $this->outside->getPremiumRate($amount->getCurrency(), $this->targetCurrency); } else { $this->rate = $this->outside->getStandardRate($amount->getCurrency, $this->targetCurrency); } } private function assertExchangeLimitDoesNotExceed(): void { if ($this->outside->getDailyLimit($this->createdAt, $this->userId) < $this->amount->getValue()) { throw new RuntimeException('Exchange limit exceeded!'); } } }
Более того на этапе написания бизнес кода мы можем вообще не задумываться над реализацией интерфейса outside. Мы можем полностью реализовать логику на уровне домена, протестировать ее с помощью юнит тестов, а реализацию outside передать другому разработчику, у которого меньше опыта в применении DDD.
Что мы имеем в итоге:
Вся доменная логика находится внутри доменного объекта, а не размазана по внешними сервисам
У агрегата есть только одна внешняя зависимость максимально заточенная под потребности агрегата, интерфейс который он сам и определяет
Создание мока для этой зависимости намного проще чем создание моков для нескольких зависимостей которые напрямую не связанны с агрегатом.
Разработку можно разделить на этапы:
На пером этапе мы имплементируем бизнес логику не задумываясь о интерфейсах и деталях реализации инфраструктуры которая обеспечиваeт нас данным для принятия бизнес решений
На втором этапе подключаем агрегат через outside к действующей инфраструктуре и реализуем те части инфраструктуры которых еще не существует
