slm-design/docs/README.md

layout, title, description, hero, features

layout	title	description	hero	features
home	Архитектура фронтенд-приложений	SLM Design помогает командам сохранять понятную структуру и предсказуемо развивать фронтенд-приложения по мере роста продукта.	name text tagline image actions SLM Design Архитектура фронтенд-приложений Практичная модель для растущих команд и продуктов. Меньше споров о структуре, безопаснее изменения и понятнее код. src alt /logo.svg SLM Design theme text link brand Узнать, как это работает /architecture/ theme text link alt Посмотреть правила /rules/registry	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. Где заканчивается область жизни ресурсов?
6. Какой доменный контракт и какие ошибки определены до подключения источника данных?

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

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

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

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

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

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

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

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

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

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

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

Спроектировать первый модуль · Спроектировать домен · Разобрать зависимости · Проверить существующую структуру