Files
slm-design/DRAFT/level-3/README.md

97 lines
6.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# SLM Level 3
> Статус: рабочий черновик. Документы в этой папке не являются спецификацией.
Level 3 предназначен для приложений со сложной предметной логикой, несколькими средами выполнения или длительным сроком поддержки. Он не добавляет новый слой, а задаёт явное и проверяемое устройство доменов внутри слоя `domains`.
## Когда выбирать Level 3
Level 3 оправдан, когда предметная область имеет устойчивый контракт бизнес-логики, несколько технических интеграций, разные способы сборки для браузера и сервера либо сложный жизненный цикл ресурсов.
Количество файлов или размер проекта сами по себе не требуют перехода. Предметная область без такой сложности оформляется доменным модулем Level 2.
## Наследование предыдущих уровней
Проект Level 3 соблюдает определения и правила Level 1 и Level 2, кроме явно заменённых положений.
| Положение | Статус в Level 3 |
|---|---|
| Порядок `app → compositions → domains → infra → ui → shared` | Сохраняется |
| Модуль, группа, сегмент, компонент, публичный API и жизненный цикл | Сохраняют смысл Level 1 |
| Доменный модуль Level 2 и [`SLM-L2-DOMAIN-R001`](../rules/level-2.md#slm-l2-domain-r001) | Заменяются доменом Level 3 |
| Группа внутри `domains` | Может содержать домены, оставаясь навигационной папкой |
| Прямые дочерние модули домена | Не являются вложенными, потому что домен сам не является модулем |
Домен не содержит исполняемого кода и не отменяет правило Level 1 о модульном владельце. Он задаёт предметную границу, а конкретной ответственностью, публичным API и жизненным циклом по-прежнему владеет модуль.
## Основная идея
```text
Домен задаёт предметную границу.
Модуль бизнес-логики определяет правила, сценарии и публичный контракт.
Порты описывают возможности, которые нужны бизнес-логике.
Адаптеры реализуют порты в конкретной среде.
Типовые сборки повторяемо создают API.
Модуль фреймворка связывает готовый API с React, Vue или другим фреймворком.
Владелец графа удерживает экземпляр API и завершает его жизненный цикл.
```
## Базовая форма домена
```text
src/domains/
└── auth/ # домен
├── business/ # обязательный модуль
│ ├── errors/
│ ├── lib/
│ ├── ports/
│ ├── services/
│ ├── types/
│ └── index.ts
├── presets/ # необязательная группа
│ └── application/ # модуль типовой сборки
│ ├── adapters/
│ └── index.ts
├── adapters/ # необязательная группа
│ └── identity-provider/ # самостоятельный модуль адаптера
│ └── index.ts
└── react/ # модуль фреймворка
├── hooks/
├── providers/
└── index.ts
```
Модуль `business` обязателен. Группы `presets` и `adapters`, а также модули фреймворков появляются только при реальной потребности. Каталоги `types`, `errors`, `lib`, `services`, `tests`, `ui`, `client` и `server` не становятся самостоятельными корневыми ветками домена.
Домен может находиться непосредственно в `domains` или внутри навигационной группы. Группа не меняет его границы, направление зависимостей и доступность модулей домена.
## Публичные границы
У корня домена нет общей точки входа для исполняемого кода. Внешний код импортирует публичный API конкретного модуля:
```ts
import { authFactory, isAuthError } from '@/domains/auth/business'
import { createApplicationAuth } from '@/domains/auth/presets/application'
import { AuthProvider, useAuth } from '@/domains/auth/react'
```
`@/domains/auth/business` является публичным API отдельного модуля, а не глубоким импортом. Пути вида `@/domains/auth/business/services/...` и общий импорт `@/domains/auth` нарушают границу.
## Карта черновика
- [Терминология](./terminology.md)
- [Граница домена](./domains/domain.md)
- [Модуль бизнес-логики](./domains/business.md)
- [Фабрика, порты и адаптеры](./domains/factory-ports-adapters.md)
- [Типовые сборки и SSR](./domains/presets.md)
- [Модуль React](./domains/framework-bindings.md)
- [Зависимости](./dependencies.md)
- [Тестирование](./domains/testing.md)
- [Проверка](./validation.md)
- [Пример переноса домена](./domains/auth-example.md)
- [Открытые вопросы](./domains/open-questions.md)
## Канонические правила
Level 3 использует правила Level 1 и Level 2, а также [дополнительный реестр Level 3](../rules/level-3.md). Тематические документы объясняют правила, но не объявляют их повторно.