Здравствуйте, Буравчик, Вы писали:

Б>Как известно, в чистой архитектуре, есть три вида компонент:
Б>- 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)
Б>- делать псевдо-юскейсы для получения настроек. Минус — те же, что и в предыдущем пункте.

Б>Как делать лучше/проще/понятнее?

Можно сделать отдельную модель для всякого рода настроек со своими use case -> repository.Вообще слой — это абстракция и вполне может содержать внутри себя тоже чистую архитектуру для своего функционирования.