7.2 KiB
Слои
Слой классифицирует код по архитектурной роли. Слой не владеет ответственностью: владельцем остаётся модуль, размещённый в этом слое.
Слой выбирается после определения ответственности. Похожее имя папки или наличие зависимости от конкретной библиотеки не являются основанием для выбора слоя.
Роли слоёв
SLM определяет шесть ролей:
| Слой | Роль |
|---|---|
app |
Связь приложения с фреймворком: запуск, маршруты, преобразование внешних входных данных и подключение готовых публичных API |
compositions |
Сборка продуктового интерфейса: страницы, макеты, экраны, виджеты и другие композиции |
domains |
Предметные модели, правила, сценарии и продуктовое состояние |
infra |
Технические сервисы и возможности приложения без собственной предметной модели |
ui |
Универсальные интерфейсные модули без зависимости от конкретной продуктовой композиции |
shared |
Детерминированный фундамент без знания о продукте, изменяемого состояния и ввода-вывода |
Отсутствующая роль не требует пустой папки. Проект создаёт слой только тогда, когда в нём появляется соответствующая ответственность.
App
app содержит точки связи с фреймворком: запуск, файлы маршрутов и преобразование внешних входных данных. Они подключают готовые публичные API других слоёв, но не присваивают их ответственность.
Точки входа app являются специальным немодульным исключением. Самостоятельная продуктовая ответственность, даже если она представлена страницей, макетом или Provider, реализуется в подходящем модуле и только подключается из app.
Compositions
compositions содержит владельцев продуктовых композиций: страниц, макетов, экранов, виджетов, результатов маршрутов и интерфейса, объединяющего несколько ответственностей.
Конкретная организация слоя определяется продуктом и фреймворком. Названия pages, layouts, screens и widgets могут использоваться как группы, но не являются дополнительными слоями и не задают направление импортов.
Domains
domains содержит модули-владельцы предметных ответственностей: моделей, правил, сценариев и продуктового состояния.
Доменный модуль является обычным SLM-модулем. Ему не требуется отдельная архитектурная форма только потому, что он находится в domains.
Infra
infra содержит технические возможности приложения: аналитику, локализацию, тему, телеметрию, интеграции с платформой и другие сервисы без собственной предметной модели.
Технический способ выполнения предметного сценария не переносит владение сценарием из domains в infra.
UI
ui содержит универсальные интерфейсные модули, которые не знают о конкретной странице, маршруте или продуктовой композиции.
Shared
shared содержит детерминированный фундамент, не зависящий от продукта и не имеющий ввода-вывода, изменяемого состояния или жизненного цикла.
В shared могут находиться обычные модули и небольшие немодульные ресурсы: чистые функции, общие типы, стили, декларативная конфигурация и статические файлы.
Направление зависимостей
Слой ограничивает только межслойное направление. Модули одного слоя могут зависеть друг от друга через публичные API, если общий граф остаётся ацикличным.
Нормативная матрица, правила same-layer импортов и требования к lint-проверке находятся в разделе Зависимости.
Группировка
Модули могут находиться непосредственно в слое или объединяться в необязательные навигационные группы. Группа не владеет кодом и не влияет на допустимость зависимостей.
Немодульные исключения
Внутри SLM root код по умолчанию принадлежит модулю. Исключения ограничены двумя случаями:
- точка входа
appнепосредственно связывает приложение с фреймворком; - ресурс
sharedявляется небольшой самостоятельной детерминированной единицей без внутренней границы.
Если ресурсу shared нужны несколько файлов реализации, собственные архитектурные зависимости, изменяемое состояние, ввод-вывод или жизненный цикл, ему требуется модуль-владелец.