Skip to main content

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

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