slm-design/DRAFT/level-3/domains/open-questions.md

Открытые вопросы 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

Варианты:

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 в монотонную шкалу архитектурных уровней. Более высокий уровень должен добавлять требования и не отменять правила предыдущего.

Предварительный вариант:

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.