**Scoped Layered Module Design (SLM)** - архитектурная модель для организации кода внутри фронтенд-приложения. Она описывает владельцев поведения, роли слоёв, границы модулей, публичные API и допустимые зависимости.
Цель SLM - сделать архитектурные решения наблюдаемыми в структуре проекта: понимать, какой модуль отвечает за результат, что доступно его потребителям и как изменение повлияет на остальное приложение.
Или [скачать `slm-design.zip`](https://gromlab-ru.github.io/slm-design/downloads/slm-design.zip).
## О чём SLM
SLM отвечает на три основных вопроса:
1. Какой модуль владеет конкретным результатом или поведением?
2. Какие возможности модуль открывает внешним потребителям?
3. От каких других модулей он может зависеть?
Базовый принцип модели: **у каждой самостоятельной ответственности есть ровно один модуль-владелец**.
Модуль определяет публичный API ответственности, её зависимости, модели и правила, состояние, жизненный цикл и внутреннюю реализацию. Компонент, Provider, hook, store или service остаются механизмами реализации и не становятся отдельными архитектурными владельцами только из-за своей технической роли.
SLM применяется внутри `SLM root` - границы структурной архитектуры одного приложения. Конкретный проект сам сопоставляет свои пути с сущностями SLM.
## Структурная модель
```text
SLM root
└── слой
├── модуль
│ ├── публичные фасеты
│ ├── сегменты
│ └── вложенные модули
└── группа
└── модули
```
| Сущность | Назначение |
|---|---|
| `SLM root` | Ограничивает область архитектуры одним приложением |
| Слой | Классифицирует код по архитектурной роли и ограничивает направления зависимостей |
| Модуль | Владеет одной самостоятельной ответственностью и её публичным API |
| Домен | Специализирует модуль для предметной ответственности и доменных сценариев |
| Группа | Навигационно классифицирует модули, но не владеет кодом или API |
| Сегмент | Организует внутренний код одного модуля без собственной ответственности |
| Вложенный модуль | Владеет отдельной подответственностью внутри родительского модуля |
Слой, группа и сегмент не являются владельцами. По умолчанию код внутри `SLM root` принадлежит ближайшему модулю; исключениями остаются точки входа `app` и небольшие детерминированные ресурсы `shared`.
## Слои
SLM определяет шесть архитектурных ролей:
| Слой | Роль |
|---|---|
| `app` | Запуск приложения, маршруты, преобразование внешних входов и подключение готовых публичных API |
| `compositions` | Представление и связывание готовых возможностей в страницы, макеты, экраны и виджеты |
| `domains` | Предметные ответственности и сценарии: модели, правила, состояние, операции с данными и доменный UI |
| `infra` | Технические сервисы без собственной предметной модели |
| `ui` | Универсальные интерфейсные модули без знания о конкретном продукте или странице |
| `shared` | Детерминированный фундамент без продуктового знания, ввода-вывода и изменяемого состояния |
Проект создаёт только те слои, для которых появился соответствующий код. Пустые слои и обязательное прохождение через каждый промежуточный уровень не требуются.
## Ключевые свойства
- **Один владелец ответственности.** Контракт, состояние, зависимости и внутренняя реализация связного результата принадлежат одному модулю.
- **Закрытая модульная граница.** Внешний код использует модуль только через его публичные фасеты. Глубокие импорты во внутренние файлы запрещены.
- **Фасеты сред выполнения.** Обязательный `index` содержит универсальный API; `client`, `browser` и `server` добавляются только при необходимости.
- **Вертикальные домены.** Домен владеет сценарием целиком: предметным контрактом, правилами, состоянием, ошибками, доменным UI и адаптацией источников данных.
- **Независимость от DTO.** Внешние request, response и error types остаются внутри интеграционной границы и не становятся публичной моделью домена.
- **Ацикличный модульный граф.** Межмодульные импорты проходят через публичный API, учитывают направление слоёв и не образуют циклов.
- **Рост по ответственности.** Сегменты организуют внутренний код, а новый или вложенный модуль появляется только для самостоятельной ответственности.
- **Владение состоянием и ресурсами.** Модуль определяет источник истины, область жизни, число экземпляров и очистку долгоживущих ресурсов.
## Проверка архитектуры
SLM разделяет смысловые и структурные решения.
-На архитектурном ревью проверяются ответственность, единственный владелец, роль слоя, состав публичного API, доменный контракт, состояние и жизненный цикл.
- Автоматически можно проверять направления между слоями, доступ через публичные фасеты, отсутствие глубоких импортов и циклов в модульном графе.
Блокирующие правила собраны в едином реестре и имеют стабильные коды. Рекомендации и примеры объясняют модель, но не подменяют нормативные требования.
## Что SLM не определяет
SLM не требует конкретного фреймворка, state manager, способа получения данных или потока управления. Модель не задаёт фиксированные имена сегментов, полный файловый стайлгайд и правила организации монорепозитория.
Эти решения остаются за проектом. SLM определяет только архитектурный смысл владельцев, границ и зависимостей внутри одного приложения.
