SOP: Слоёная доменная архитектура

Используйте этот SOP, когда агент постоянно нарушает границы, дублирует логику между слоями или производит код, который через несколько сессий становится сложно ревьюить.

Цель

Сделать доменные границы достаточно явными, чтобы агенты могли двигаться быстро, не разрушая структуру тихим образом.

Целевая модель

Внутри бизнес-домена предпочитайте такой направленный поток:

Types -> Config -> Repo -> Service -> Runtime -> UI

Сквозные сущности должны попадать через явные провайдеры или адаптеры. Общие утилиты остаются вне домена и не должны накапливать доменную логику.

Чеклист настройки

• Определите текущие домены в ARCHITECTURE.md.
• Запишите допустимые направления зависимостей в ARCHITECTURE.md.
• Зафиксируйте сквозные интерфейсы: аутентификация, телеметрия, внешние API.
• Добавьте короткую заметку о самом тяжёлом текущем нарушении границ.
• Решите, что должно проверяться механически линтером, тестами или скриптами.

SOP исполнения

1. Разметьте кодовую базу по доменам, прежде чем трогать стиль реализации.
2. Для каждого домена определите допустимую последовательность слоёв.
3. Идентифицируйте все сквозные сущности и проводите их через провайдеры или адаптеры.
4. Перенесите неоднозначную общую логику либо в её домен-владелец, либо в действительно универсальные утилиты.
5. Документируйте правила в ARCHITECTURE.md.
6. Добавьте один исполняемый ограничитель для самого дорогого нарушения.
7. Обновите скоринг качества после изменения.

Definition Of Done

• Свежий агент может сказать, какому слою принадлежит изменение.
• UI-код больше не лезет напрямую в репозиторий или внешние сайд-эффекты.
• У сквозных сущностей есть именованные точки входа.
• Хотя бы одна важная граница соблюдается механически.

Артефакты репозитория для обновления

• ARCHITECTURE.md
• docs/QUALITY_SCORE.md
• docs/design-docs/, когда изменилась обосновывающая логика
• docs/PLANS.md или активный exec plan