slm-design/docs/architecture/README.md

# Архитектура SLM

SLM описывает владение ответственностями внутри одного фронтенд-приложения. Слой определяет роль кода, группа классифицирует модули, модуль владеет ответственностью, а сегмент организует реализацию владельца.

## Владение как основа

**Ответственность** — связная часть приложения с одной причиной изменяться. Она становится самостоятельной, когда ей нужны собственный публичный контракт, зависимости, состояние или область жизни.

У каждой самостоятельной ответственности есть ровно один владелец. В SLM владельцем является модуль. Он определяет:

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

Место выполнения кода не меняет владельца. Компонент, провайдер, маршрут или точка запуска могут технически вызывать код ответственности, но не получают владение ею автоматически.

## Структурная модель

```text
SLM root
└── слой
    ├── модуль
    │   └── сегмент
    └── группа
        ├── модуль
        └── группа
            └── модуль
                └── сегмент
```

| Сущность | Назначение | Владеет ответственностью |
|---|---|---|
| Слой | Классифицирует код по архитектурной роли | Нет |
| Группа | Классифицирует модули внутри слоя | Нет |
| Модуль | Реализует одну самостоятельную ответственность | Да |
| Сегмент | Организует внутренности одного модуля | Нет |

Слой и группа находятся снаружи модульной границы. Сегмент находится внутри неё. Компоненты, хуки, сервисы, хранилища и другие детали реализации принадлежат ближайшему модулю-владельцу, если сами не образуют вложенный модуль.

## Порядок проектирования

Архитектурное решение принимается от смысла к структуре:

1. Описать результат или поведение, за которое должен отвечать код.
2. Определить одну причину изменения этой ответственности.
3. Найти связанные данные, поведение, состояние и жизненный цикл.
4. Назначить модуль владельцем и определить его внешних потребителей.
5. Выбрать [слой](./layers.md) по роли ответственности.
6. Спроектировать публичный API и допустимые зависимости [модуля](./modules.md).
7. При необходимости организовать реализацию [сегментами](./segments.md).
8. Только после этого выбрать физические пути и имена файлов.

Если ответственность или владелец не определены, файловая структура не может исправить архитектурную неопределённость.

## Логическая и физическая границы

Модуль не определяется наличием папки, `index.ts` или нескольких файлов. Его определяет самостоятельная ответственность и владение её контрактом, зависимостями, состоянием и жизненным циклом.

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

Верны обе формулировки:

- самостоятельная ответственность требует модульной границы;
- отдельная папка сама по себе не доказывает наличие модуля.

Пути сопоставляются со слоями, группами, модулями и сегментами в стайлгайде или конфигурации конкретного проекта. Имя пути не меняет нормативный смысл сущности.

## Область применения

SLM применяется внутри **SLM root** — границы структурной архитектуры одного приложения. Это может быть `src/` или другая область, установленная проектом.

Архитектура определяет:

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

SLM не задаёт обязательный поток данных, полный файловый стайлгайд, фиксированный набор сегментов, правила монорепозиториев или обязательную внутреннюю форму каждого модуля.

Нормативный смысл терминов находится в [терминологии](../reference/terminology.md). Точные блокирующие требования объявлены только в [реестре правил](../rules/registry.md).