Архитектура SLM
SLM описывает владение ответственностями внутри одного фронтенд-приложения. Слой определяет роль кода, группа классифицирует модули, модуль владеет ответственностью, а сегмент организует реализацию владельца.
Владение как основа
Ответственность — связная часть приложения с одной причиной изменяться. Она становится самостоятельной, когда ей нужны собственный публичный контракт, зависимости, состояние или область жизни.
У каждой самостоятельной ответственности есть ровно один владелец. В SLM владельцем является модуль. Он определяет:
- какие возможности доступны внешним потребителям;
- от каких других возможностей зависит ответственность;
- кому принадлежат данные и изменяемое состояние;
- когда создаются и уничтожаются долгоживущие ресурсы;
- как устроена внутренняя реализация.
Место выполнения кода не меняет владельца. Компонент, провайдер, маршрут или точка запуска могут технически вызывать код ответственности, но не получают владение ею автоматически.
Структурная модель
SLM root
└── слой
├── модуль
│ └── сегмент
└── группа
├── модуль
└── группа
└── модуль
└── сегмент
| Сущность | Назначение | Владеет ответственностью |
|---|---|---|
| Слой | Классифицирует код по архитектурной роли | Нет |
| Группа | Классифицирует модули внутри слоя | Нет |
| Модуль | Реализует одну самостоятельную ответственность | Да |
| Сегмент | Организует внутренности одного модуля | Нет |
Слой и группа находятся снаружи модульной границы. Сегмент находится внутри неё. Компоненты, хуки, сервисы, хранилища и другие детали реализации принадлежат ближайшему модулю-владельцу, если сами не образуют вложенный модуль.
Порядок проектирования
Архитектурное решение принимается от смысла к структуре:
- Описать результат или поведение, за которое должен отвечать код.
- Определить одну причину изменения этой ответственности.
- Найти связанные данные, поведение, состояние и жизненный цикл.
- Назначить модуль владельцем и определить его внешних потребителей.
- Выбрать слой по роли ответственности.
- Спроектировать публичный API и допустимые зависимости модуля.
- При необходимости организовать реализацию сегментами.
- Только после этого выбрать физические пути и имена файлов.
Если ответственность или владелец не определены, файловая структура не может исправить архитектурную неопределённость.
Логическая и физическая границы
Модуль не определяется наличием папки, index.ts или нескольких файлов. Его определяет самостоятельная ответственность и владение её контрактом, зависимостями, состоянием и жизненным циклом.
После принятия решения модуль получает отдельную папку и публичные точки входа. Это обязательное физическое представление модульной границы, необходимое потребителям и автоматическим проверкам.
Верны обе формулировки:
- самостоятельная ответственность требует модульной границы;
- отдельная папка сама по себе не доказывает наличие модуля.
Пути сопоставляются со слоями, группами, модулями и сегментами в стайлгайде или конфигурации конкретного проекта. Имя пути не меняет нормативный смысл сущности.
Область применения
SLM применяется внутри SLM root — границы структурной архитектуры одного приложения. Это может быть src/ или другая область, установленная проектом.
Архитектура определяет:
- роли слоёв и допустимые направления зависимостей;
- владельцев самостоятельных ответственностей;
- публичные границы модулей;
- назначение групп и сегментов;
- владение состоянием и жизненным циклом ресурсов.
SLM не задаёт обязательный поток данных, полный файловый стайлгайд, фиксированный набор сегментов, правила монорепозиториев или обязательную внутреннюю форму каждого модуля.
Нормативный смысл терминов находится в терминологии. Точные блокирующие требования объявлены только в реестре правил.