NestJS изначально предлагает организовывать приложение вокруг модулей. Обычно структура строится по функциональным областям:
src/
├── users/
│ ├── users.module.ts
│ ├── users.controller.ts
│ ├── users.service.ts
│ └── dto/
│
├── orders/
│ ├── orders.module.ts
│ ├── orders.controller.ts
│ └── orders.service.ts
│
└── app.module.ts
Такой подход удобен тем, что всё, что относится к одной функциональности, находится в одном месте.
Но существует и другой вариант организации проекта — разделить приложение по архитектурным слоям.
Например:
src/
├── api/ # транспортный слой
├── services/ # бизнес-логика и прикладные модули
├── repositories/ # доступ к данным
├── entities/ # модели
├── integrations/ # внешние сервисы
├── auth/
├── common/
├── app.module.ts
└── main.ts
В такой структуре верхний уровень проекта сразу показывает основные части системы.
api отвечает за взаимодействие с внешним миром:
- контроллеры;
- маршруты;
- DTO;
- обработку входящих данных.
services содержит основные модули приложения:
- бизнес-логику;
- сценарии работы;
- взаимодействие между компонентами.
repositories и integrations выделяются как отдельные слои для работы с данными и внешними системами.
Главное отличие такого подхода в том, что граница проходит не по функциональности, а по роли компонента в приложении.
Поток становится более явным:
Request
|
v
API
|
v
Service
|
+--> Repository
|
+--> Integration
Преимущество такой организации — в общей читаемости проекта. Открывая структуру, сразу видно, где находится транспортный слой, где бизнес-логика, а где инфраструктурные компоненты.
Такой вариант может быть удобен для проектов, где есть несколько способов взаимодействия с приложением или где хочется явно отделить внешний интерфейс от внутренней реализации.
Это не замена стандартной модульной организации NestJS, а другой способ группировки кода — выбор зависит от размера проекта и архитектурных предпочтений команды.
Добавить комментарий