Другие архитектуры: плюсы и минусы
По типу, по фичам, Atomic Design, Clean/Hexagonal и монорепозиторий.
Обновлено
Что вы сравниваете
«Лучшей» архитектуры нет — есть подходящая под размер проекта, команду и сложность предметной области. Ниже — самые распространённые варианты во фронтенде, с плюсами, минусами и тем, когда их выбирать.
1. По типу файлов (by type)
src/components/ src/hooks/ src/utils/ src/services/ src/types/
+ нулевая кривая обучения, идеально для маленьких проектов / прототипов. − при 100+ файлах превращается в «ящик со старьём»; фича разбросана по 5 папкам; никаких правил зависимостей.
Когда: лендинг, личный проект, < ~30 компонентов.
2. По фичам / модулям (Bulletproof React)
src/features/
auth/ components/ api/ hooks/ types/
cart/ components/ api/ hooks/ types/
src/components/ (общие)
+ высокая связность, легко понять, хорошо масштабируется; простое правило: фичи не импортируют друг друга. − правил меньше, чем в FSD → «куда положить код, который используют 2 фичи?» решает команда.
Когда: большинство средних приложений. Самая популярная альтернатива FSD.
3. Atomic Design
atoms/ (Button, Input) → molecules/ (SearchField) → organisms/ (Header) → templates/ → pages/
+ отлично для дизайн-системы / UI kit; общий словарь с дизайнерами. − организует только интерфейс, а не логику и данные; граница molecule/organism субъективна.
Когда: библиотеки компонентов, Storybook. Может жить внутри shared/ui другой архитектуры.
4. Clean / Hexagonal (Ports & Adapters)
domain/ сущности + чистые правила, без фреймворка
application/ use case-ы (createOrder)
infrastructure/ БД, API, конкретные реализации
ui/ React
+ бизнес-логика полностью независима от фреймворка → тестируема, переносима. − много бойлерплейта (интерфейсы, адаптеры); во фронтенде это часто оверинжиниринг.
Когда: сложная предметная область (финтех, ERP), логика, общая для web/mobile/backend.
5. Монорепозиторий (Turborepo / Nx)
apps/web apps/admin apps/mobile
packages/ui packages/config packages/db
Это не альтернатива, а уровень выше: несколько приложений, делящих пакеты. Каждое приложение выбирает свою внутреннюю архитектуру (часто FSD или по фичам).
+ настоящий общий код, кэшированные сборки. − сложность инструментов.
Быстрое сравнение
| Размер проекта | Правила | Кривая обучения | Бизнес-логика | |
|---|---|---|---|---|
| По типу | маленький | мало | лёгкая | разбросана |
| По фичам | средний–большой | средне | лёгкая | по фичам |
| FSD | средний–большой | строгие | средняя | entities/features |
| Atomic | UI kit | только UI | лёгкая | — |
| Clean/Hexagonal | большой, сложный | строгие | тяжёлая | изолированный домен |
Как выбрать
- Маленький проект или прототип → по типу, переедете позже.
- Продуктовое приложение, маленькая команда → по фичам.
- Приложение будет расти, несколько разработчиков, нужны правила, которые проверяет инструмент → FSD.
- Дизайн-система → atomic внутри
shared/ui. - Очень сложная предметная область → идеи из clean architecture (чистая логика отдельно), не обязательно весь ритуал.
Худшая архитектура — та, что применяется непоследовательно. Выберите одну, запишите правила в README и проверяйте их линтером.
Коротко
- По типу — для маленьких проектов; по фичам — для большинства приложений; FSD — когда нужны строгие правила.
- Atomic Design — для UI kit; Clean Architecture — для сложных доменов; монорепозиторий — для нескольких приложений.
- Выберите одну, задокументируйте, проверяйте линтером.