Модули задают границы частей приложения
Модуль объединяет связанную функциональность: например, пользователей, заказы или каталог. Внутри модуля находятся контроллеры, провайдеры и импортируемые зависимости. Это помогает видеть архитектуру не как длинный список файлов, а как набор областей ответственности. Хорошая граница модуля определяется бизнес-смыслом, а не случайным техническим признаком. Если логика заказов разбросана по всему приложению, изменения становятся рискованнее; если она собрана в понятном модуле, связи легче контролировать.
Контроллер принимает запрос, сервис выполняет работу
Контроллер отвечает за внешний HTTP-интерфейс: маршрут, параметры, тело запроса и формирование ответа. Сложную бизнес-логику лучше не помещать прямо в обработчик маршрута. Её переносят в сервис или другой провайдер, который можно использовать повторно и тестировать отдельно. Например, контроллер создаёт запрос на оформление заказа, а сервис проверяет правила, обращается к хранилищу и возвращает результат. Такое разделение уменьшает связанность кода.
Внедрение зависимостей упрощает замену компонентов
NestJS управляет созданием провайдеров через контейнер зависимостей. Класс объявляет, какие сервисы ему нужны, а фреймворк передаёт подходящие экземпляры. Это полезно не только ради красивой архитектуры. В тестах настоящую базу данных можно заменить имитацией, а реализацию отправки уведомлений — тестовым объектом. Код меньше зависит от конкретного способа создания компонентов, поэтому его проще расширять и проверять.
Валидация должна происходить на границе системы
Данные из сети нельзя считать корректными только потому, что TypeScript знает тип переменной во время разработки. После запуска типы не защищают приложение от неправильного JSON. Поэтому входные данные проверяют во время выполнения: обязательные поля, формат, допустимые значения и ограничения. Для этого удобно использовать DTO и механизм валидации. Ошибка должна обнаруживаться до того, как некорректные данные попадут в бизнес-логику или базу.
Попробуйте на практике
Спроектировать небольшой модуль задач в NestJS.
- Создайте мысленную структуру TaskModule, TaskController и TaskService и опишите ответственность каждого.
- Определите два маршрута: создание задачи и получение списка задач.
- Запишите поля DTO для создания задачи и правила проверки входных данных.
- Определите зависимость сервиса от репозитория или другого слоя хранения.
- Опишите, чем заменить хранилище в модульном тесте сервиса.
Как проверить результат. Архитектура готова, если HTTP-детали находятся в контроллере, бизнес-правила в сервисе, данные валидируются на входе, а хранилище можно заменить без переписывания основной логики.
Частые вопросы
NestJS — это отдельная среда выполнения?
Нет. Он работает в экосистеме Node.js и организует серверное приложение через собственные абстракции, декораторы и систему внедрения зависимостей.
Нужно ли создавать отдельный модуль для каждой сущности?
Не обязательно. Границы модулей лучше выбирать по функциональности и ответственности, а не механически по каждой таблице или классу.
Почему TypeScript не заменяет валидацию запросов?
Типы TypeScript в основном существуют во время разработки и компиляции. Реальные данные приходят во время выполнения, поэтому их нужно проверять отдельно.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.