SOP: Багаторівнева доменна архітектура

Використовуйте цей SOP, коли агент постійно порушує межі, дублює логіку між шарами або виробляє код, який стає важко рев'ювати після кількох сесій.

Мета

Зробити доменні межі достатньо явними, щоб агенти могли рухатися швидко без непомітної деградації структури.

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

Усередині бізнес-домену надавайте перевагу такому напрямку потоку:

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

Наскрізні аспекти мають входити через явні провайдери або адаптери. Спільні утиліти залишаються поза доменом і не повинні накопичувати доменну логіку.

Контрольний список налаштування

• Визначити поточні домени в ARCHITECTURE.md.
• Записати дозволені напрями залежностей в ARCHITECTURE.md.
• Зафіксувати наскрізні інтерфейси: аутентифікацію, телеметрію, зовнішні API.
• Додати одну коротку нотатку про найскладніше поточне порушення межі.
• Вирішити, що має бути забезпечено механічно — лінтером, тестами або скриптами.

Виконання SOP

1. Нанести кодову базу на карту доменів до змін стилю реалізації.
2. Для кожного домену визначити допустиму послідовність шарів.
3. Виявити всі наскрізні аспекти та маршрутизувати їх через провайдери або адаптери.
4. Перемістити неоднозначну спільну логіку або в домен-власник, або в справді загальні утиліти.
5. Задокументувати правила в ARCHITECTURE.md.
6. Додати один виконуваний захисний бар'єр для порушення з найвищою вартістю.
7. Оновити оцінку якості після змін.

Визначення завершення

• Свіжий агент може визначити, якому шару належить зміна.
• UI-код більше не звертається безпосередньо до репозиторію або зовнішніх побічних ефектів.
• Наскрізні аспекти мають іменовані точки входу.
• Принаймні одна важлива межа забезпечена механічно.

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

• ARCHITECTURE.md
• docs/QUALITY_SCORE.md
• docs/design-docs/ коли обґрунтування змінилось
• docs/PLANS.md або активний план виконання