Как известно, в чистой архитектуре, есть три вида компонент:
— input adapter (например, эндпоинт http api)
— use case c логикой приложения
— output adapter (например, repository БД)
Обычно последовательность вызовов такая: input adapter -> use case -> repository
Но что делать, если некоторые настройки для input adapter находятся в БД, т.е. для работы input adapter нужно получить данные из repository
Примеры:
— проверка идемпотентности (ключи хранятся в БД)
— фиче-флаг, отключающий эндпоинт (флаг хранится в БД)
— проверка прав доступа (права доступа хранятся в БД)
— rate limiter хитрый (настройки хранятся в БД)
Варианты, как я вижу:
— перенести логику проверки из input adapter в use case. Минус — логика приложения может загрязняться деталями инфры
— ходить за настройкам из input adapter напрямую в репозиторий. Минус — на каждый вызов будет две транзакция — для получения настроек и для выполнения use case (хотя одна может быть к RO, вторая к RW)
— делать псевдо-юскейсы для получения настроек. Минус — те же, что и в предыдущем пункте.
