architecture-boundaries

name	architecture-boundaries
description	Архитектурные границы: FSD/VSA/Hexagonal, modules, APIs, imports. Используй для: слои, границы. EN: architecture boundaries, public API.

Architecture Boundaries

Purpose

Keep systems easy to understand, change, and scale by using stable architecture boundaries and project-consistent placement.

Default Architecture

• 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.
• Important architecture or technology decisions require an ADR or equivalent decision record.

Frontend And Client UI

• Prefer FSD layers: app, pages, widgets, features, entities, shared.
• Do not use processes by default because it is deprecated in modern FSD.
• 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

• Group use-case code vertically when practical: command/query/route input, validation, handler, domain logic, persistence, and response contract should be easy to trace together.
• Minimize cross-slice coupling. Shared backend code must be stable, genuinely reusable, and not a dumping ground.
• Avoid generic service/repository layers when they only pass data through and add no useful abstraction.
• Cross-cutting concerns such as auth, logging, observability, transactions, and error mapping must be explicit and consistently placed.

Read references/architecture-policy.md when deciding placement or documenting an ADR.