mirror of
https://github.com/gromlab-ru/slm-design.git
synced 2026-08-22 07:30:16 +03:00
88 lines
8.5 KiB
Markdown
88 lines
8.5 KiB
Markdown
# Терминология Level 3
|
||
|
||
> Нормативные определения рабочего черновика. Этот раздел не объявляет правила.
|
||
|
||
Level 3 наследует терминологию Level 1 и Level 2 и заменяет доменный модуль Level 2 новой структурной сущностью — доменом Level 3.
|
||
|
||
## Домен Level 3
|
||
|
||
### Домен
|
||
|
||
Немодульная предметная граница слоя `domains`, представляющая одну самостоятельную предметную область. Домен объединяет модули и группы этой области, но не имеет собственного исполняемого кода, состояния, жизненного цикла, публичного API или узла графа зависимостей.
|
||
|
||
Домен не является ни модулем, ни группой. Он может находиться непосредственно в слое `domains` или внутри навигационной группы этого слоя. Такая группа вправе содержать домены, но сохраняет остальные свойства группы Level 1.
|
||
|
||
Модуль, расположенный непосредственно внутри домена или одной из его групп, не считается вложенным: его ближайшая внешняя граница не является модулем.
|
||
|
||
### Модуль домена
|
||
|
||
Модуль внутри домена, ответственность которого соответствует одной технической роли: бизнес-логике, типовой сборке, адаптеру или связи с фреймворком. Каждый модуль домена остаётся обычным модулем Level 1 со своим публичным API и узлом графа зависимостей.
|
||
|
||
### Модуль бизнес-логики
|
||
|
||
Обязательный модуль `business` внутри домена. Он определяет публичные предметные сценарии и контракты, фабрику, порты, ошибки предметной области, детерминированные правила и модель состояния.
|
||
|
||
Модуль `business` не зависит от конкретной среды выполнения, технической реализации или фреймворка.
|
||
|
||
### Порт
|
||
|
||
Минимальный контракт возможности, которая нужна бизнес-логике для выполнения предметного сценария. Порт принадлежит модулю `business`, использует язык предметной области и не раскрывает SDK, сгенерированные DTO, хранилище, хук, объект платформы или другую техническую реализацию.
|
||
|
||
### Фабрика
|
||
|
||
Функция модуля `business`, которая получает полный набор портов и создаёт экземпляр публичного API бизнес-логики. Фабрика не выбирает реализации портов и не является готовой сборкой для конкретной среды.
|
||
|
||
### Адаптер
|
||
|
||
Код, который реализует один или несколько портов поверх конкретного SDK, хранилища, API платформы, данных запроса, системы управления состоянием или технического сервиса. Адаптер может быть закрытым сегментом модуля сборки либо самостоятельным модулем в группе `adapters`.
|
||
|
||
### Типовая сборка
|
||
|
||
Модуль в группе `presets`, который повторяемо создаёт API одной фабрики для именованного контекста выполнения. Он выбирает реализации портов и возвращает вызывающему коду операции, необходимые для управления жизненным циклом созданного экземпляра.
|
||
|
||
### Модуль фреймворка
|
||
|
||
Модуль домена, который связывает публичный API бизнес-логики с конкретным фреймворком. Он размещается непосредственно в домене и называется именем фреймворка: `react`, `vue` и аналогично. Такой модуль получает готовый API, но не вызывает фабрику и не реализует технические адаптеры.
|
||
|
||
### Место сборки
|
||
|
||
Место, которое вызывает фабрику, передаёт полный набор портов и получает экземпляр API. Повторяемое место сборки оформляется модулем в группе `presets`; одноразовая сборка принадлежит явному владельцу графа. Модуль фреймворка не является местом сборки.
|
||
|
||
### Владелец графа
|
||
|
||
Код модуля, который удерживает собранный граф и его экземпляры API в пределах объявленной области жизни, а также вызывает предоставленные операции запуска и очистки. Владелец графа не заменяет владельца ресурса: контракт жизненного цикла определяет модуль, которому принадлежит ресурс, по правилам Level 1.
|
||
|
||
Владельцем графа может быть модуль приложения, маршрута, страницы, запроса или теста.
|
||
|
||
### Граница среды выполнения
|
||
|
||
Граница между графами импортов, предназначенными только для клиента, только для сервера или для обеих сред. Она определяется достижимостью импортов, а не названием папки или удалением неиспользуемого кода при сборке.
|
||
|
||
## Виды владения
|
||
|
||
Level 3 разделяет три разных вопроса:
|
||
|
||
| Вопрос | Ответственный |
|
||
|---|---|
|
||
| Какая предметная область и словарь объединяют код | Домен |
|
||
| Кто владеет самостоятельной ответственностью и публичным API | Конкретный модуль |
|
||
| Кто удерживает экземпляры API и завершает их жизненный цикл | Владелец графа |
|
||
|
||
Например, модуль `business` владеет моделью `AuthState` и допустимыми переходами между её состояниями. Модуль, содержащий адаптер, владеет конкретным механизмом хранения и определяет контракт его жизненного цикла. Владелец графа удерживает созданный `AuthApi` в допустимой области жизни и вызывает очистку.
|
||
|
||
## Структурная модель
|
||
|
||
```text
|
||
корень SLM
|
||
└── domains
|
||
└── домен
|
||
├── модуль business
|
||
├── группа presets
|
||
│ └── модуль типовой сборки
|
||
├── группа adapters
|
||
│ └── модуль адаптера
|
||
└── модуль react
|
||
```
|
||
|
||
Группы `presets` и `adapters` существуют только при наличии соответствующих модулей. Каталоги `errors`, `ports`, `services`, `types`, `hooks` и `providers` являются сегментами своих модулей-владельцев, если сами не образуют самостоятельный модуль.
|