chore: границы доменов

docs/reference/validation.md

@@ -14,6 +14,10 @@
 | Вопрос | Что зафиксировать |
 |---|---|
 | Ответственность | Какой результат или поведение изменяется как единое целое |
+| Доменный сценарий | Какой модуль `domains` владеет предметным результатом и через какой API его используют внешние потребители, включая композиции |
+| Доменный контракт | Какие входы, модели и результаты определены предметным смыслом независимо от источника данных |
+| Доменные ошибки | Какие ожидаемые неуспешные исходы определяет домен и где проходит граница с programming defects |
+| Граница источника | Какие внешние контракты получает домен и как они адаптируются к предметному смыслу |
 | Владелец | Какой модуль определяет контракт и внутреннюю реализацию |
 | Слой | Какой архитектурной роли соответствует ответственность |
 | Потребители | Кому действительно нужен публичный API |
@@ -30,6 +34,12 @@
 
 - одна ли связная ответственность находится внутри модульной границы;
 - есть ли у каждой самостоятельной ответственности ровно один ближайший владелец;
+- принадлежит ли каждый доменный сценарий модулю слоя `domains`;
+- находятся ли бизнес-правила, продуктовое состояние, смысл операций с предметными данными, предметные исходы и доменный UI у владельца сценария;
+- только ли использует и компонует модуль `compositions` готовые публичные API доменов, не определяя и не дополняя их сценарии;
+- не размещён ли сценарий временно в композиции только потому, что подходящий доменный модуль ещё не создан;
+- не скрывает ли связывание нескольких доменных API новый порядок, условие, общий предметный результат или политику ошибок;
+- обслуживает ли прямое использование `infra` собственную техническую потребность композиции, а не продуктовую операцию или доступ к предметным данным;
 - соответствует ли ответственность роли выбранного слоя;
 - владеет ли вложенный модуль отдельно сформулированной подответственностью;
 - не стали ли группа или сегмент скрытыми владельцами;
@@ -43,6 +53,33 @@
 
 Окончательные смысловые требования имеют класс `R` в [реестре правил](../rules/registry.md).
 
+Вызовы `fetch`, HTTP-клиента, SDK, query client или storage внутри `compositions` являются сигналами для проверки, но не самостоятельным доказательством нарушения. Ревью устанавливает, обслуживает ли вызов техническую ответственность самой композиции или реализует доменный сценарий в обход его владельца.
+
+## Проверка домена
+
+Для каждого создаваемого или изменяемого домена дополнительно проверяется:
+
+- остаётся ли домен одним специализированным модулем и узлом графа, а не неявным контейнером нескольких владельцев;
+- объявлены ли входы, модели и результаты самим доменом до подключения источника;
+- можно ли описать доменный контракт без упоминания endpoint, SDK, DTO или схемы внешнего сервиса;
+- не выведен ли публичный тип через alias, наследование, `Pick`, `Omit`, `ReturnType` или другой source type;
+- определены ли ожидаемые неуспешные исходы самим доменом;
+- создаёт ли реализация только исходы, объявленные доменным контрактом;
+- не определяют ли mapper, adapter или framework-код независимые ошибки параллельно декларации домена;
+- зависит ли потребитель только от error contract текущего домена независимо от выбранной формы его представления;
+- не выдаётся ли project policy о code, payload, union или casing за универсальное правило SLM;
+- отсутствуют ли в публичной ошибке чужие error type, source code, message, transport status, raw payload и `cause`;
+- адаптируются ли request и response источника выбранным внутренним механизмом;
+- попадают ли в правила, состояние и доменный UI только значения доменного контракта;
+- интерпретируется ли каждая ошибка источника и зависимого домена в терминах текущего сценария;
+- нужен ли runtime-механизм идентификации реальным потребителям и совместим ли он с их средой выполнения;
+- не экспортируется ли constructor, guard, parser или schema без доказанной потребности;
+- не замаскирована ли programming defect под ожидаемую доменную ошибку.
+
+Прямой импорт source type во внутренний код адаптации сам по себе допустим. Нарушением является его достижимость из публичного фасета, использование как доменной модели или состояния либо передача потребителю без преобразования.
+
+Интеграционный код ревьюится только после определения доменного контракта и семантики ожидаемых ошибок. Запрос к реальному источнику не считается допустимой временной реализацией домена, если предметная граница ещё не объявлена.
+
 ## Автоматическая проверка
 
 Проект сопоставляет физические пути с SLM root, слоями, группами, модулями, вложенными модулями, сегментами, фасетами, точками входа `app` и ресурсами `shared`. Сопоставление задаётся локальной конфигурацией и не меняет смысл сущностей.
@@ -107,6 +144,16 @@ File-level проверка не заменяет модульную: два м
 Изменение соответствует SLM, когда одновременно выполнены условия:
 
 - ответственность и единственный ближайший владелец определены;
+- каждый доменный сценарий целиком принадлежит модулю `domains` и используется композициями только через его публичный API;
+- отсутствие готового доменного модуля не привело к временной реализации сценария в `compositions`;
+- междоменная координация с собственным продуктовым результатом получила доменного владельца;
+- каждый домен остаётся специализированным модулем и самостоятельно объявляет предметный контракт;
+- публичный API домена не содержит DTO, source types или чужие error contracts;
+- все внешние значения адаптированы к доменному контракту до использования в правилах, состоянии или доменном UI;
+- ожидаемые неуспешные исходы определены текущим доменом независимо от способа их представления;
+- реализация и интеграции используют только исходы, объявленные доменным контрактом;
+- ошибки источников и зависимых доменов не пересекают публичную границу в исходной форме;
+- runtime-идентификация предоставлена только при наличии реального потребителя и совместима с его средой;
 - роль слоя соответствует ответственности;
 - публичный API минимален и используется всеми внешними потребителями;
 - зависимости разрешены и не образуют модульных циклов;