Принципы архитектуры

Что такое архитектура фронтенд-проекта

Архитектура = правила, по которым вы организуете код: где лежит каждый файл, кто кого может импортировать и как части общаются между собой. Речь не о фреймворке (React, Next), а о структуре вашего кода поверх него.

Почему архитектура важна

При 10 файлах подходит любая структура. При 500 структура решает, найдёте ли вы код за 5 секунд или за 5 минут и сломает ли изменение 1 место или 15.

5 принципов, лежащих в основе любой архитектуры

1. Высокая связность (cohesion) — то, что меняется вместе, лежит вместе. Компонент, хук, типы и запрос для «корзины» — в одном месте.

2. Слабое зацепление (coupling) — модули знают друг о друге как можно меньше. Общаются через маленькие интерфейсы (props, экспортируемые функции), а не через внутренние детали.

3. Направление зависимостей — зависимости текут в одну сторону: от конкретного кода (страниц) к общему (утилитам). Никогда наоборот. Так вы избегаете циклических импортов.

views→features→entities→shared

Наоборот (shared импортирует из features) — запрещено.

4. Понятный публичный интерфейс — каждый модуль сам решает, что выставлять наружу. Остальное — внутренняя деталь, которую можно свободно менять.

5. Colocation — держите вещи как можно ближе к месту использования. Что-то становится «общим», только когда реально используется в 2–3 местах.

Признаки, что архитектура не работает

• «Куда положить этот файл?» — вопрос каждый день.
• Папка utils/ или components/ с 80 несвязанными файлами.
• Меняете компонент — ломается страница, которая «была ни при чём».
• Импорты вида ../../../../shared/x.
• Удаляете фичу, а её куски остаются по всему проекту.

Практические правила при любой архитектуре

• Описательные имена файлов (site-header.tsx, а не index.tsx × 40).
• Бизнес-логика не живёт в UI-компонентах — выносите её в чистые (тестируемые) функции.
• Доступ к данным (fetch, SQL) — в одном слое, а не разбросан по компонентам.
• Линтер может следить за правилами импорта (например, eslint-plugin-boundaries, Steiger для FSD).

Коротко

• Архитектура = где лежит код и кто кого может импортировать.
• Высокая связность, слабое зацепление, зависимости в одну сторону.
• Понятный публичный интерфейс, colocation, бизнес-логика отдельно от UI.

Официальные источники

• Next.js — Project Structure
• react.dev — Thinking in React
• Kent C. Dodds — Colocation