architecture-boundarieslisted

# Architecture Boundaries ## Purpose Keep systems easy to understand, change, and scale by using stable architecture boundaries and project-consistent placement. ## Default Architecture (May 2026) - Existing project architecture is the source of truth. Do not rewrite architecture just to satisfy a generic rule. - New frontend, web UI, mobile UI, and desktop UI areas default to **Feature-Sliced Design** when the stack allows it. - New backend areas default to **Vertical Slice Architecture** when the application is use-case, command, query, route, or handler oriented. Combine with **Hexagonal (Ports & Adapters)** for framework-agnostic durability and **Modular Monolith** as the organizational container for medium-scale systems. - Important architecture or technology decisions require an ADR (MADR 4.0.0 format) or equivalent decision record. ## Frontend And Client UI (FSD) - Prefer FSD layers: `app`, `pages`, `widgets`, `features`, `entities`, `shared`. - Treat the deprecated `processes` layer as forbidden by default; route its responsibilities into `app`/`pages`/`widgets` depending on scope. - Imports should point only to lower layers, except `app` and `shared` rules and explicit project exceptions. - Use public APIs for slices. Avoid deep imports into slice internals. - Keep `shared` business-agnostic. Business concepts belong in `entities`, `features`, `widgets`, or `pages`. ## Backend (VSA + Hexagonal + Modular Monolith) - **VSA**: organize around use cases, commands