docs/projects/slm-design/canons/architecture/index.md

title, description

title	description
SLM Design	Назначение архитектуры, ключевые принципы и карта разделов документации

SLM Design

Scoped Layered Module Design — модульная архитектура фронтенд-приложений. Код организован по слоям ответственности, а модуль содержит всё, что ему нужно: компоненты, хуки, сторы, типы, стили.

Разделы спецификации

Спецификация SLM Design состоит из нескольких связанных разделов. Этот обзор даёт общий контекст, а детальные правила описаны дальше:

• Слои — уровни организации src/, направление зависимостей и зона ответственности каждого слоя.
• Модули — границы ответственности, публичный API, типы модулей и отличие модуля от компонента.
• Сегменты — внутренние папки модуля (ui/, parts/, hooks/, types/ и другие) и правила размещения файлов.
• Монорепозитории — применение SLM в apps/ и packages/, правила выноса общих слоёв и ограничения для business/compositions.

Рекомендуемый порядок чтения: обзор → слои → модули → сегменты → монорепозитории.

Преимущества

Единый слой композиции

Страницы, маршруты и крупные продуктовые части интерфейса собираются в compositions. Слой не навязывает жёсткую структуру: команда может использовать pages/layouts/screens/widgets или другую организацию под свой фреймворк и продукт.

Вертикальная организация домена

Бизнес-домен не разбивается по техническим слоям — сценарии, сущности, типы и UI живут в одном модуле. Это сокращает время навигации и упрощает сопровождение: все изменения домена локализованы.

Dependency Injection без фреймворков

Cross-domain зависимости в бизнес-слое реализуются через фабрики — модуль декларирует что ему нужно, а точка использования предоставляет зависимости. Домены изолированы без DI-контейнеров, провайдеров и шин событий.

Разделение ответственности без перегрузки слоёв

Композиция приложения (compositions/), сервисы приложения (infra/), UI-кит (ui/) и общие ресурсы (shared/) — разные слои с разной природой. Ни один слой не превращается в свалку разнородного кода.

Графовая композиция там, где она нужна

Внутри compositions допускается граф импортов через публичный API. Это позволяет page-level store, provider или business composition использовать одновременно в layout, screen и widget, не перенося продуктовый runtime-state в infra или shared.

Горизонтальная инкапсуляция

Вложенные модули (parts/) и публичные API позволяют нескольким разработчикам работать над одной областью приложения параллельно, не затрагивая код друг друга.

Колокация по умолчанию

Код начинает жизнь рядом с местом использования и поднимается в общие слои только при реальной потребности. Глобальные слои не засоряются преждевременными абстракциями.

Масштабирование через группировку

При росте проекта слои не теряют структуру — модули группируются по естественным признакам: композиции по страницам и маршрутам, бизнес-домены по субдоменам, UI-компоненты по уровню абстракции.

Адаптация к монорепозиториям

SLM применяется внутри каждого приложения, а packages/* используются только для общего кода из слоёв ui, infra и shared. compositions и бизнес-домены остаются внутри приложений, чтобы не размывать продуктовые границы.

Происхождение

SLM Design вырос на основе:

• Feature-Sliced Design — слоистая структура, публичный API модуля, направление зависимостей
• Vertical Slice Architecture — модуль как вертикальный срез, содержащий всё необходимое
• Screaming Architecture — структура проекта «кричит» о назначении: открыл business/auth — видишь авторизацию
• Colocation Principle — код живёт рядом с местом использования

Пример структуры проекта

src/
├── app/
│
├── compositions/
│   ├── pages/
│   │   ├── home/
│   │   ├── profile/
│   │   └── product-detail/
│   ├── layouts/
│   │   ├── main/
│   │   └── dashboard/
│   ├── screens/
│   │   ├── home/
│   │   └── profile/
│   └── widgets/
│       ├── page-heading/
│       └── promo-banner/
│
├── business/
│   ├── auth/
│   ├── catalog/
│   ├── orders/
│   └── chat/
│
├── infra/
│   ├── theme/
│   ├── i18n/
│   ├── backend-api/
│   └── logger/
│
├── ui/
│   ├── button/
│   ├── input/
│   ├── modal/
│   ├── toast/
│   └── dropdown/
│
└── shared/
    ├── lib/
    ├── types/
    └── styles/

Принципы

• Композиция — отдельный слой. Страницы, маршруты и крупные продуктовые части интерфейса собираются в compositions.
• Структура композиции свободна. Команда сама выбирает организацию внутри compositions; базовая рекомендация — pages/layouts/screens/widgets.
• Домен — единое целое. Всё, что относится к домену, живёт в одном business-модуле.
• Колокация. Код рождается рядом с местом использования и поднимается только при необходимости.
• Зависимости однонаправлены за пределами compositions. Глобальная стрелка: app → compositions → business → infra → ui → shared.
• Внутри compositions допустим граф. Composition modules могут импортировать друг друга через public API.
• Архитектура — каркас, не клетка. Правила фиксируют границы ответственности и public API, а внутреннюю форму композиции определяет команда.