---
layout: home
title: Архитектура фронтенд-приложений
description: SLM Design помогает командам сохранять понятную структуру и предсказуемо развивать фронтенд-приложения по мере роста продукта.

hero:
  name: SLM Design
  text: Архитектура фронтенд-приложений
  tagline: Практичная модель для растущих команд и продуктов. Меньше споров о структуре, безопаснее изменения и понятнее код.
  image:
    src: /logo.svg
    alt: SLM Design
  actions:
    - theme: brand
      text: Узнать, как это работает
      link: /architecture/
    - theme: alt
      text: Посмотреть правила
      link: /rules/registry

features:
  - title: Один язык для всей команды
    details: Разработчики одинаково понимают границы, ответственность и место нового кода. Архитектурные решения перестают зависеть от личных предпочтений.
  - title: Предсказуемые изменения
    details: Локальная правка остаётся локальной. Команда может развивать внутреннюю реализацию, не переписывая половину приложения.
  - title: Рост без хаоса
    details: Структура усложняется только вместе с продуктом, а не из-за количества файлов, компонентов или выбранных библиотек.
  - title: Архитектура видна в репозитории
    details: Правила выражены кодом и структурой проекта, поэтому документация не расходится с реальным приложением.
  - title: Независимость от стека
    details: SLM не требует конкретного фреймворка, state manager или способа работы с данными и не ограничивает внутреннюю реализацию.
  - title: Постепенное внедрение
    details: Начните с одного спорного участка и расширяйте модель по мере необходимости, без полной перестройки приложения.
---

## Папки перестают быть архитектурой, когда продукт начинает расти

На старте почти любая структура выглядит понятной. Затем появляются десятки компонентов, общие hooks, Providers, stores, глубокие импорты и модули, которые знают друг о друге слишком много. Папки остаются на месте, но границы ответственности исчезают.

SLM возвращает архитектуре наблюдаемый смысл:

> **Модуль владеет ответственностью. Весь код внутри ближайшей модульной границы реализует её.**

Это правило одинаково работает для страницы, доменного сценария, UI-библиотеки, инфраструктурного сервиса и небольшого внутреннего модуля.

## Что меняется для команды

| Когда границ нет | С SLM Design |
|---|---|
| Решение о размещении кода принимается по похожей папке | Сначала определяется ответственность и её владелец |
| Компоненты и services становятся скрытыми архитектурными центрами | Любой внутренний механизм остаётся реализацией ближайшего модуля |
| Потребители импортируют удобный внутренний файл | Чужой модуль доступен только через публичный фасет |
| Циклы обнаруживаются во время большого рефакторинга | Модульный граф можно проверять lint-инструментами |
| Новые уровни создаются из-за размера каталога | Вложенный модуль появляется только для самостоятельной подответственности |

Результат: меньше случайной связанности, меньше споров о папках и предсказуемый радиус каждого изменения.

## Не ещё один шаблон директорий

SLM не диктует, какие библиотеки, state managers или framework-механизмы использовать. Внутри модуля могут находиться компоненты, Providers, Guards, hooks, stores, services, utilities и сторонние SDK.

Архитектура отвечает на другие вопросы:

1. За какой результат отвечает этот код?
2. Какой модуль владеет его контрактом и состоянием?
3. Что действительно нужно внешним потребителям?
4. Какие зависимости допустимы и не создают ли они цикл?
5. Где заканчивается область жизни ресурсов?

Файловая структура появляется после ответов, а не заменяет их.

## От одного файла до дерева владельцев

Модуль может начинаться с одного главного файла и расти без смены архитектурной сущности:

```text
checkout/
├── index.ts                    # Публичный контракт
├── checkout.tsx                # Главная реализация
├── components/                 # Внутренний код checkout
├── hooks/
├── services/
└── modules/
    └── form-session/           # Самостоятельная подответственность
        ├── index.ts
        ├── form-session.provider.tsx
        └── hooks/
```

Размер, количество файлов и framework-роли не создают владельца. Только отдельно сформулированная ответственность получает модульную границу.

## Правила, которые можно проверить

SLM разделяет смысловые решения и структурные инварианты:

- ответственность, владелец и минимальный публичный контракт проверяются на архитектурном ревью;
- направления между слоями, глубокие импорты, публичные фасеты и модульные циклы проверяются автоматически;
- каждый rule имеет стабильный код и одно место нормативной формулировки;
- framework-компоненты не образуют бесконечную файловую рекурсию, а новые уровни появляются только через вложенные модули.

Вы получаете не абстрактный набор рекомендаций, а модель, которую можно обсуждать одинаковыми терминами, видеть в репозитории и постепенно автоматизировать.

## Начните с одной ответственности

Не нужно переписывать приложение целиком. Выберите один спорный участок, сформулируйте его ответственность, назначьте владельца и закройте внутреннюю реализацию публичным API. Этого достаточно, чтобы увидеть разницу между папкой и архитектурной границей.

[Спроектировать первый модуль](./architecture/modules.md) · [Разобрать зависимости](./architecture/dependencies.md) · [Проверить существующую структуру](./reference/validation.md)