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

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

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

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

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

Б>Но что делать, если некоторые настройки для input adapter находятся в БД, т.е. для работы input adapter нужно получить данные из repository

Настройки должны получаться из другого input adapter, в роли которого может выступать репозиторий, но не тот который output adapter.

А вообще, чистая архитектура это ересь неприменимая в реальной жизни. Равно как и прочие творения Мартина.

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

ИМХО:

Б>- проверка идемпотентности (ключи хранятся в БД)
База даст отлуп запросу, это вернётся клиенту в конце раундтрипа. Это не настройка эндпоинта.

Б>- фиче-флаг, отключающий эндпоинт (флаг хранится в БД)
Это задача должна решаться на edge — сервисе — это не часть самого сервиса, а внешний компонент со своими настройками до входа в сервис.

Б>- проверка прав доступа (права доступа хранятся в БД)
Это задача authentication server — это внеший к сервису компонент со своими настройками. Частью сервиса не является.

Б>- rate limiter хитрый (настройки хранятся в БД)
Аналогично предыдущим двум.

Ржать не громко — я такими делами занимался исключительно как хобби.

Б> Как известно, в чистой архитектуре, есть три вида компонент:
Б> ...
Б> Как делать лучше/проще/понятнее?

Надо выбрать либо "чистую архитектуру", либо "лучше/проще/понятнее"

Имхо, порты и адаптеры в том абстрактном виде, как их описывает Фаулер, штука мало применимая на практике.

Можно порассуждать от обратного.
Этот код однозначно не относится к доменой логике (domain).
И не относится к use-case приложения, т.е. это не application layer.
К presentation его тоже, вроде как, не отнесешь.
Что остается? А остается инфраструктура (infrastructure).

Т.е. с точки зрения presentation/application-слоя это просто набор интерфейсов: IIdempotencyManager, IFeatureFlagsProvider, IAuthenticationService, IRateLimiterConfiguration и т.п.
Которые физически лежит в какой-нибудь общедоступной сборке, e.g. Infrastructure.Abstractions.
А конкретная реализация интерфейсов уже может быть какой угодно: внешний сервис, отдельная БД (со собственной моделью данных в терминах EF-Core), нереляционное хранилище (e.g. mongo, zookeeper, s3 и т.п.).
И эти реализации никак не связаны ни с domain, ни с application, ни с адаптерами (репозиториями) основного приложения.