| 1 | # ADR 0006: Слои, вертикальные срезы и роль MainWindowViewModel |
| 2 | |
| 3 | **Статус:** Accepted |
| 4 | **Дата:** 2026-04-02 |
| 5 | ## Связанные ADR |
| 6 | |
| 7 | ### Вне ADR |
| 8 | |
| 9 | | Документ | Роль | |
| 10 | |----------|------| |
| 11 | | [Features/README.md](../Features/README.md) | Features/README | |
| 12 | | [architecture-migration.md](../architecture-migration.md) | architecture migration | |
| 13 | |
| 14 | --- |
| 15 | ## Контекст |
| 16 | |
| 17 | Нужна предсказуемая структура одного десктопного приложения (Avalonia + MVVM) без обязательного DDD или hexagonal на весь код, но с явными границами, чтобы не получить неподдерживаемый God ViewModel и не смешивать UI, сценарии и доступ к диску и процессам. |
| 18 | |
| 19 | ## Решение |
| 20 | |
| 21 | ### Горизонтальные слои |
| 22 | |
| 23 | - **UI** — Views (AXAML), code-behind только для задач представления (`Views/`). |
| 24 | - **Presentation** — ViewModels, команды, биндинги (`ViewModels/`). |
| 25 | - **Application / domain logic** — сценарии без привязки к Avalonia: парсеры, координация (`Services/`, часть). |
| 26 | - **Infrastructure** — файлы, процессы, git, HTTP, MCP-транспорт (`Services/`, часть; `IdeMcpServer`). |
| 27 | |
| 28 | **Правило:** ViewModel не содержит прямых деталей запуска процессов и чтения файлов, если это можно отдать сервису с интерфейсом (или узкому статическому helper с одной ответственностью). |
| 29 | |
| 30 | ### Вертикальные срезы (фичи) |
| 31 | |
| 32 | Крупная возможность (панель Git, терминал, отладка, чат) оформляется как срез: базово `Features/<Имя>/` и неймспейс `CascadeIDE.Features.<Имя>`; допустимо иное согласованное размещение, главное — единообразие. |
| 33 | |
| 34 | **Правило:** новая нижняя или боковая панель или крупный блок — отдельный `*ViewModel`, по возможности отдельный `*View`. |
| 35 | |
| 36 | ### MainWindowViewModel |
| 37 | |
| 38 | **Композитор:** создаёт дочерние VM, пробрасывает зависимости, реагирует на события уровня окна (смена решения, закрытие). Допустим мост к MCP. |
| 39 | |
| 40 | **Не** хранить здесь объёмную логику новой фичи (десятки методов git, парсинг путей, поиск решений) — вынос в панельный VM и сервисы. |
| 41 | |
| 42 | ### Модели списков и модули |
| 43 | |
| 44 | - Модели строк списков (`Models/GitStatusRow` и аналоги): данные и флаги для отображения, без тяжёлой бизнес-логики. |
| 45 | - Один новый модуль — один понятный корень неймспейса (например `CascadeIDE.Features.Git`). |
| 46 | |
| 47 | ## Последствия |
| 48 | |
| 49 | Новые фичи проектируются по слоям и срезам; перенос старого кода из монолитного VM — постепенно, см. [architecture-migration.md](../architecture-migration.md). |
| 50 | |
| 51 | ## Отклонённые альтернативы |
| 52 | |
| 53 | - Вводить полный DDD или обязательный hexagonal на весь код по умолчанию — отклонено как избыточное для текущего масштаба. |
| 54 | |