mirror of
https://github.com/gromlab-ru/slm-design.git
synced 2026-08-22 07:30:16 +03:00
114 lines
5.7 KiB
Markdown
114 lines
5.7 KiB
Markdown
|
# Открытые вопросы Domains
|
|||
|
|
|
|||
|
|
> Эти вопросы намеренно не сформулированы как правила.
|
|||
|
|
|
|||
|
|
## Ошибки
|
|||
|
|
|
|||
|
|
### OPEN-N001: Throw или typed Result
|
|||
|
|
|
|||
|
|
Нужно решить, остаются ли ожидаемые domain failures исключениями с public runtime guard или business API возвращает discriminated `Result<T, DomainError>`.
|
|||
|
|
|
|||
|
|
Текущий совместимый вариант: throw + `isDomainError`. Typed Result потребует изменения формы всех scenario methods.
|
|||
|
|
|
|||
|
|
### OPEN-N002: Универсальный или domain-specific error guard
|
|||
|
|
|
|||
|
|
Нужно определить, достаточно ли общего `isDomainError`, либо каждый business-модуль экспортирует `isAuthError`, `isUserError` и собственную проверку code set.
|
|||
|
|
|
|||
|
|
## Domain structure
|
|||
|
|
|
|||
|
|
### OPEN-N003: Имена framework modules
|
|||
|
|
|
|||
|
|
Варианты:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
domains/auth/framework/react
|
|||
|
|
domains/auth/bindings/react
|
|||
|
|
domains/auth/react
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
`framework/react` явно классифицирует роль, `react` сокращает import path, а `bindings/react` подчёркивает adapter-like назначение границы. Выбор пока не сделан.
|
|||
|
|
|
|||
|
|
### OPEN-N004: Нужен ли root Domain entrypoint
|
|||
|
|
|
|||
|
|
Статус: предварительно закрыт в пользу нескольких entrypoints.
|
|||
|
|
|
|||
|
|
Каждый public module Domain предоставляет собственную точку входа: business, конкретный preset, framework binding и promoted adapter. Обязательный root runtime barrel не создаётся, потому что он может смешать isomorphic, client-only и server-only graphs.
|
|||
|
|
|
|||
|
|
### OPEN-N005: Public adapters
|
|||
|
|
|
|||
|
|
Текущая гипотеза: adapter начинается как private segment минимального владельца, обычно preset module. При появлении самостоятельной ответственности или нескольких assembly consumers он может быть поднят в отдельный adapter module с собственным entrypoint.
|
|||
|
|
|
|||
|
|
Открытым остаётся точный promotion criterion; фиксированная числовая граница пока не выбрана.
|
|||
|
|
|
|||
|
|
## Factory и ports
|
|||
|
|
|
|||
|
|
### OPEN-N006: Гранулярность одной factory
|
|||
|
|
|
|||
|
|
Одна factory может возвращать большой API, хотя конкретному SSR scope нужны два метода. Нужно проверить, достаточно ли narrowed preset view, или крупные contracts требуют нескольких business modules/factories.
|
|||
|
|
|
|||
|
|
Предварительный принцип: одна factory на один связный business API contract; разные environments сами по себе не создают новую factory.
|
|||
|
|
|
|||
|
|
### OPEN-N007: Reactive state contract
|
|||
|
|
|
|||
|
|
Нужно проверить на реальном Zustand/React/SSR кейсе форму framework-neutral state port:
|
|||
|
|
|
|||
|
|
- `getSnapshot` + `subscribe`;
|
|||
|
|
- commands/selectors;
|
|||
|
|
- initial server snapshot;
|
|||
|
|
- hydration;
|
|||
|
|
- cleanup;
|
|||
|
|
- concurrent rendering.
|
|||
|
|
|
|||
|
|
## Framework boundary
|
|||
|
|
|
|||
|
|
### OPEN-N008: Domain-specific UI
|
|||
|
|
|
|||
|
|
Нужно решить, какие auth components принадлежат выбранному Auth framework binding module, а какие остаются composition widgets/screens.
|
|||
|
|
|
|||
|
|
Framework dependency сама по себе не доказывает Domain ownership.
|
|||
|
|
|
|||
|
|
## Cross-domain dependencies
|
|||
|
|
|
|||
|
|
### OPEN-N009: Прямой импорт pure functions другого Domain
|
|||
|
|
|
|||
|
|
Нужно определить, может ли business одного Domain напрямую импортировать pure function другого Domain или cross-domain связь всегда должна проходить через `Deps`.
|
|||
|
|
|
|||
|
|
Возможный компромисс:
|
|||
|
|
|
|||
|
|
- type-only contracts разрешены;
|
|||
|
|
- runtime API передаётся через ports;
|
|||
|
|
- pure function import разрешён только как явно зафиксированная ацикличная Domain dependency.
|
|||
|
|
|
|||
|
|
## Уровни архитектуры
|
|||
|
|
|
|||
|
|
### OPEN-N010: На каком уровне появляется Domain
|
|||
|
|
|
|||
|
|
Нужно встроить Domain в монотонную шкалу архитектурных уровней. Более высокий уровень должен добавлять требования и не отменять правила предыдущего.
|
|||
|
|
|
|||
|
|
Предварительный вариант:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
Level 1: modules
|
|||
|
|
Level 2: layers
|
|||
|
|
Level 3: domains
|
|||
|
|
Level 4: runtime-safe factories, ports, presets и verification
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Точная классификация будет выполнена после извлечения атомарных правил из legacy-документации и этих заметок.
|
|||
|
|
|
|||
|
|
## Проверяемость
|
|||
|
|
|
|||
|
|
### OPEN-N011: Architecture lint
|
|||
|
|
|
|||
|
|
Будущие проверки могут контролировать:
|
|||
|
|
|
|||
|
|
- запрещённые imports из `business/**`;
|
|||
|
|
- отсутствие server-only graph в isomorphic entrypoint;
|
|||
|
|
- отсутствие client framework в factory graph;
|
|||
|
|
- разрешённые категории exports business public API;
|
|||
|
|
- запрет `export *` на environment boundaries;
|
|||
|
|
- cycles между Domain modules;
|
|||
|
|
- preset lifecycle declarations.
|
|||
|
|
|
|||
|
|
Семантическую чистоту функции нельзя надёжно доказать только по имени export. Для этого потребуется сочетание folder conventions, import restrictions, AST checks и public API tests.
|