| 1 | <!-- English translation of adr/0006-presentation-layers-and-feature-slices.md. Canonical Russian: ../../adr/0006-presentation-layers-and-feature-slices.md --> |
| 2 | |
| 3 | # ADR 0006: Layers, vertical slices and the role of MainWindowViewModel |
| 4 | |
| 5 | **Status:** Accepted |
| 6 | **Date:** 2026-04-02 |
| 7 | ## Related ADRs |
| 8 | |
| 9 | ### Outside ADR |
| 10 | |
| 11 | | Document | Role | |
| 12 | |----------|------| |
| 13 | | [Features/README.md](../Features/README.md) | Features/README | |
| 14 | | [architecture-migration.md](../architecture-migration.md) | architecture migration | |
| 15 | |
| 16 | --- |
| 17 | ## Context |
| 18 | |
| 19 | We need a predictable structure of one desktop application (Avalonia + MVVM) without mandatory DDD or hexagonal for the entire code, but with clear boundaries so as not to get an unsupported God ViewModel and not to mix UI, scripts and access to disk and processes. |
| 20 | |
| 21 | ## Solution |
| 22 | |
| 23 | ### Horizontal layers |
| 24 | |
| 25 | - **UI** - Views (AXAML), code-behind only for view tasks (`Views/`). |
| 26 | - **Presentation** — ViewModels, commands, bindings (`ViewModels/`). |
| 27 | - **Application / domain logic** - scripts not tied to Avalonia: parsers, coordination (`Services/`, part). |
| 28 | - **Infrastructure** - files, processes, git, HTTP, MCP transport (`Services/`, part; `IdeMcpServer`). |
| 29 | |
| 30 | **Rule:** ViewModel does not contain direct details of running processes and reading files if this can be given to a service with an interface (or a narrow static helper with one responsibility). |
| 31 | |
| 32 | ### Vertical slices (features) |
| 33 | |
| 34 | A large feature (Git panel, terminal, debugging, chat) is designed as a slice: base `Features/<Name>/` and namespace `CascadeIDE.Features.<Name>`; Other agreed placement is acceptable, the main thing is uniformity. |
| 35 | |
| 36 | **Rule:** a new bottom or sidebar or large block is a separate `*ViewModel`, if possible a separate `*View`. |
| 37 | |
| 38 | ### MainWindowViewModel |
| 39 | |
| 40 | **Composer:** creates child VMs, forwards dependencies, reacts to window-level events (change of solution, closing). Let's say a bridge to MCP. |
| 41 | |
| 42 | **Do not** store here the voluminous logic of a new feature (dozens of git methods, parsing paths, searching for solutions) - export it to a panel VM and services. |
| 43 | |
| 44 | ###List Models and Modules |
| 45 | |
| 46 | - List row models (`Models/GitStatusRow` and similar): data and flags for display, without heavy business logic. |
| 47 | - One new module - one clear namespace root (for example `CascadeIDE.Features.Git`). |
| 48 | |
| 49 | ## Consequences |
| 50 | |
| 51 | New features are designed in layers and slices; migration of old code from a monolithic VM - gradually, see [architecture-migration.md](../architecture-migration.md). |
| 52 | |
| 53 | ## Rejected alternatives |
| 54 | |
| 55 | - Introduce full DDD or mandatory hexagonal on all code by default - rejected as redundant for the current scale. |