Как уменьшить сложность и тяжеловесность «контроллеров» в API приложениях?

Question

[nakonechnikistryi]

Никак не получается сделать лаконичные контроллеры, и я сомневаюсь в правильности своей архитектуры. Под контроллерами в API приложении я подразумеваю классы, которые обрабатывают http запросы по заданным адресам.

Перед моими контроллерами стоит сразу множество задач:
- валидация входящих данных
- логгировние
- общение с сервисами
- поддержать разные варианты http ответов (статусы http)

К слову внутри сервисов возникает такая же проблема: запросы в базу данных, доменная логика, обращение к внешним сервисам, маппинг данных между абстракциями. Методы становятся большими, нарушается принцип единой ответственности, тяжело поддерживать и покрывать тестами.

Есть ли какие-то рекоммендации или опыт того, как уменьшить сложность?

Comments

[Vitsliputsli]

Не нарушайте принцип единственной ответственности. Вы перечислили 4 задачи, выполняемые контроллером, даже если они все должны быть в контроллере - это 4 строчки. Откуда большие методы?

Answer 1

[Михаил]

Путь к уменьшению сложности один - декомпозиция.
Выносить все лишнее в отдельные классы и модули.
Скажем, стоит выносить логику валидации запросов из контроллера в отдельные классы, оставляя в контроллере только абстрактное: валидировать. логировать. передать на обработку. вернуть результат.
Тоже самое в сервисах: выносить логику обращения к БД, обращения к внешним сервисам и т.д., оставляя только то что относится непосредственно к ответственности сервиса

См. книгу Р. Мартин "Чистая архитектура", вот статья об этом на хабре

Comments

[nakonechnikistryi]

Спасибо. Все равно (в сервисах) появляется много кода, чтобы управлять всеми абстракциями, причем в заданном порядке. Например поступает запрос, данные этого запроса валидируются автоматически - это ладно. Но потом я должен смапить данные из запроса в данные доменной логики. Затем при ошибке отдать такой-то http статус, а если ошибки нет - сделать запись в несколько таблиц транзакционно через какую-то абстракцию, и если там пойдет что-то не так - опять отдать ошибку по http, и так далее.

Мне кажется сама по себе задача "обслужить запрос по адресу" слишком большая, и подразумевает работу большого числа абстракций вместе.

[Михаил]

Ну вот как это выглядит примерно на котлине:

return try {
  validator.validate(request)
  val domainRequest = converter.mapToDomainModel(request)
  val domainResponse = service.processRequest(domainRequest)
  converter.mapFromDomainModel(domainResponse)
} catch (ex: Throwable) {
  mapErrorResponse(ex)
}

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