frontend-docs/docs/architecture/01-classic-layer-based-arch.md

sidebar_position

sidebar_position
1

Классическая архитектура

Layer-based architecture (архитектура на основе слоёв) — это подход к организации кода, при котором приложение разделяется на несколько логических слоёв, каждый из которых отвечает за определённый аспект функциональности. Этот метод широко используется как во фронтенд-, так и в бэкенд-разработке и помогает создавать структурированные, поддерживаемые и масштабируемые приложения.

Основные идеи Layer-based Architecture

1. Разделение ответственности:
   • Каждый слой отвечает за определённую часть функциональности (например, отображение данных, управление состоянием, работа с API).
   • Это упрощает понимание кода и снижает вероятность ошибок.
2. Изоляция слоёв:
   • Слои взаимодействуют друг с другом через чётко определённые интерфейсы, что делает их независимыми.
   • Изменения в одном слое минимально влияют на другие.
3. Повторное использование:
   • Логика, вынесенная в отдельные слои, может быть переиспользована в разных частях приложения.

Основные слои во фронтенд-разработке

1. Presentation Layer (Слой представления):
   • Отвечает за отображение данных и взаимодействие с пользователем.
   • Включает компоненты, стили и UI-логику.
   • Пример: React-компоненты, Vue-компоненты, Angular-шаблоны.
2. Application Layer (Слой приложения):
   • Управляет бизнес-логикой приложения.
   • Координирует взаимодействие между слоем представления и слоем данных.
   • Пример: хуки, сервисы, контроллеры.
3. Data Layer (Слой данных):
   • Отвечает за работу с данными: получение, хранение, обновление.
   • Включает API-запросы, управление состоянием (например, Redux, MobX), локальное хранилище (localStorage, IndexedDB).
   • Пример: Redux slices, GraphQL-запросы, REST API-клиенты.
4. Infrastructure Layer (Инфраструктурный слой):
   • Включает вспомогательные функции, утилиты и инструменты, которые используются во всех слоях.
   • Пример: хелперы, утилиты, конфигурация приложения.

Пример структуры проекта с Layer-based Architecture

src/
│
├── components/            # Presentation Layer: UI-компоненты
│   ├── Button/
│   ├── Header/
│   └── Footer/
│
├── pages/                 # Presentation Layer: Страницы
│   ├── HomePage/
│   └── ProfilePage/
│
├── hooks/                 # Application Layer: Хуки для бизнес-логики
│   ├── useAuth/
│   └── useCart/
│
├── store/                 # Data Layer: Управление состоянием (Redux, Zustand)
│   ├── slices/
│   │   ├── authSlice.ts
│   │   └── cartSlice.ts
│   └── index.ts
│
├── api/                   # Data Layer: Работа с API
│   ├── authApi.ts
│   └── cartApi.ts
│
├── utils/                 # Infrastructure Layer: Утилиты и хелперы
│   ├── formatDate.ts
│   └── validateForm.ts
│
└── App.tsx                # Основной файл приложения

Преимущества Layer-based Architecture

1. Чёткая структура:
   • Код легко понять и поддерживать благодаря разделению на слои.
2. Упрощение тестирования:
   • Каждый слой можно тестировать изолированно.
3. Гибкость:
   • Слои можно заменять или модифицировать без влияния на другие части приложения.
4. Повторное использование:
   • Логика, вынесенная в отдельные слои, может быть переиспользована.

Недостатки Layer-based Architecture

1. Избыточность для небольших проектов:
   • В маленьких приложениях такая структура может показаться излишне сложной.
2. Зависимость между слоями:
   • Если не соблюдать чёткие границы, слои могут стать слишком связанными.
3. Сложность настройки:
   • Требуется время и усилия для правильной организации слоёв.

Пример взаимодействия слоёв

1. Presentation Layer:
   • Компонент CartList отображает список товаров в корзине.
2. Application Layer:
   • Хук useCart управляет логикой корзины.
3. Data Layer:
   • Redux slice управляет состоянием корзины.
4. Infrastructure Layer:
   • Утилита для форматирования цены.

Когда использовать Layer-based Architecture

• В проектах среднего и крупного размера.
• Когда требуется чёткое разделение ответственности.
• В командах, где разные разработчики работают над разными аспектами приложения.

Альтернативные подходы

1. Feature Slice Design:
   • Организация кода вокруг функциональных блоков (фич).
   • Подходит для крупных проектов с множеством фич.
2. Domain-driven Design (DDD):
   • Организация кода вокруг доменных областей (например, user, order, product).
   • Часто используется в бэкенд-разработке.

🚀 Источник: DeepSeek