Middleware и DI: два паттерна, формирующие любой backend

Два инженера описывают один и тот же backend. Один говорит: «каждый запрос проходит через auth, логирование и валидацию до обработчика». Другой говорит: «обработчик получает клиент базы, кеш и mailer, которые он сам не создавал». Они описывают один код с двух ракурсов: запрос, текущий сквозь слои, и зависимости, текущие внутрь объектов. Эти два ракурса — middleware и внедрение зависимостей, и почти каждое решение по фреймворку, которое вы примете, относится к одному из них.

Две ортогональные оси

Middleware и внедрение зависимостей отвечают на разные вопросы, и их путаница — частый источник мутной архитектуры:

• Middleware — про ось запроса: что выполняется вокруг обработчика на каждом запросе и в каком порядке. Это динамично, на каждый запрос, упорядочено: auth, логирование, парсинг тела, rate limiting. Прошлый юнит показал, почему этот порядок — граница безопасности.
• Внедрение зависимостей — про ось связывания: какие объекты куску кода дают, вместо того чтобы он конструировал их сам. Это в основном статично, решается на старте и про связанность и тестируемость: обработчик получает UserRepository, а не вызывает new UserRepository() внутри себя.

Одно — конвейер; другое — граф. Запрос путешествует по конвейеру; граф собирается один раз до того, как придёт хоть один запрос.

Зачем нужен middleware: сквозные заботы

Auth, логирование, трейсинг, сжатие и обработка ошибок нужны почти каждому эндпоинту, но не принадлежат ни одному из них. Без middleware каждый обработчик переизобретает их — несогласованно. Middleware выносит эти сквозные заботы в упорядоченные слои, оборачивающие обработчик, чтобы они были написаны один раз и применялись единообразно.

Зачем нужен DI: инверсия управления

Когда класс вызывает new EmailService() внутри себя, он приварен к этой конкретной реализации: нельзя подменить её фейком в тесте, нацелить на другой конфиг или переиспользовать класс в другом месте. Инверсия управления переворачивает это — класс объявляет, что ему нужно (отправитель писем), а что-то внешнее решает, какую конкретную реализацию он получит. Это внешнее место — корень композиции, единственная точка рядом со стартом, которая знает реальные реализации и связывает граф объектов.

Они встречаются во фреймворке

Реальные фреймворки сплавляют оба. Контроллеры NestJS разрешаются из DI-контейнера и сидят за конвейером middleware/guard/interceptor. Express держит DI неявным (вы связываете руками или цепляете к req), но модель middleware явная. Распознавать, на какой оси живёт проблема, — рефлекс сеньора: «этот эндпоинт медленный на каждом запросе» — обычно middleware; «этот класс невозможно протестировать» — обычно DI.