Архитектура приложений от монолита до FSD

1.

app
Frontend · Mobile · Backend
features
Архитектура
приложений
entities
От «без архитектуры» до Feature-Sliced Design: подходы, правила и компромиссы
shared

2.

Введение
Зачем нужна архитектура
Архитектура — договорённости о том, где живёт код и как части приложения общаются между собой.
Понятность
Изменяемость
Масштаб команды
Новый разработчик быстро находит
нужный код.
Правка одной фичи не ломает
соседние.
Люди работают параллельно и не
мешают друг другу.
Архитектура приложений · 02 / 20

3.

Big Ball of Mud
Без архитектуры
Признаки
• Все модули импортируют друг друга
• Логика размазана по компонентам
• Правка в одном месте ломает другое
• Новичку трудно войти в проект
Допустимо для прототипов, хакатонов и MVP на 1–2 человека.
Архитектура приложений · 03 / 20

4.

Классика
Слоистая архитектура
Presentation · UI
↓
Плюсы
Привычная и простая. Чёткое разделение UI, логики и данных.
Business · Domain
↓
Data · Infrastructure
Архитектура приложений · 04 / 20
Минусы
Логика «протекает» в соседние слои, слои разрастаются при
росте проекта.

5.

Слоистая: на практике
Путь запроса через слои
Запрос идёт сверху вниз, ответ — снизу вверх. Каждый слой вызывает только соседний нижний.
UI
экран, форма
→
Service
бизнес-правила
→
Repository
доступ к данным
→
API / БД
хранилище
Типичная структура
Ловушка роста
components/, services/, repositories/, models/ — папки по
техническим ролям.
Одна фича размазывается по четырём папкам, а сервисы
превращаются в «божественные объекты».
Архитектура приложений · 05 / 20

6.

Классика
Модульная архитектура
Приложение делится на независимые модули по предметным областям. Общение — только через публичный API.
Auth
Catalog
Cart
Payments
UI · логика · данные
UI · логика · данные
UI · логика · данные
UI · логика · данные
public API
public API
public API
public API
Shared kernel — общий UI-кит и утилиты
Плюсы: изоляция команд, лёгкий рефакторинг. Минусы: сложно провести границы модулей.
Архитектура приложений · 06 / 20

7.

Модульная: на практике
Структура модуля и правила
src/
Публичный API
├─ modules/
│ ├─ auth/
Модуль экспортирует наружу только index.ts.
│
│
├─ components/
│
│
├─ services/
│
│
│ └─ index.ts
└─ cart/
Зависимости
Модули не лезут во внутренности друг друга, общее выносится в shared.
└─ shared/
Размер модуля
Один модуль — одна предметная область и зона ответственности команды.
Архитектура приложений · 07 / 20

8.

Паттерны UI
MVC, MVP, MVVM
MVC
MVP
MVVM
Controller принимает ввод и меняет
Model, View её показывает. Просто, но
Controller быстро пухнет.
Presenter — посредник: View пассивна,
вся логика в Presenter. Удобно
тестировать.
ViewModel хранит состояние, View
подписывается через привязки. База
Android, SwiftUI, Vue.
Паттерны разделяют UI и логику экрана, но не описывают структуру всего проекта.
Архитектура приложений · 08 / 20

9.

Паттерны UI
Потоки данных в MVC, MVP и MVVM
MVC
View
→
Controller
→
Model
Controller обновляет Model, View перерисовывается и читает
Model напрямую.
MVP
View
→
Presenter
→
Model
View ничего не знает о Model: Presenter сам вызывает View
через интерфейс.
MVVM
View
→
ViewModel
Архитектура приложений · 09 / 20
→
Model
View привязана к ViewModel и обновляется автоматически при
смене состояния.

10.

Современные подходы
Clean и Hexagonal
Зависимости направлены только внутрь: домен ничего не знает о
фреймворке и базе данных.
• Бизнес-логика тестируется без UI и БД
• Фреймворк можно заменить
• Onion, Hexagonal — вариации одной идеи
Минус: больше слоёв и шаблонного кода.
Архитектура приложений · 10 / 20

11.

Clean: на практике
Путь запроса и инверсия зависимостей
Use Case зависит от интерфейса репозитория, а реализация (SQL, REST) подключается снаружи.
Controller
принимает запрос
→
Use Case
сценарий
→
Entity
правила домена
→
Repository
интерфейс
Dependency Inversion
Что это даёт
Домен сам объявляет интерфейсы, внешний мир их реализует.
Тесты без БД и сети, замена фреймворка без переписывания
логики.
Архитектура приложений · 11 / 20

12.

Современные подходы
Feature-Sliced Design
app
инициализация, роутинг, провайдеры
pages
экраны приложения
Правило
widgets
крупные блоки интерфейса
Слой импортирует
только слои ниже
features
действия пользователя
entities
бизнес-сущности
shared
UI-кит, утилиты, API-клиент
Архитектура приложений · 12 / 20
Слайсы одного слоя друг о
друге не знают.

13.

FSD на практике
Структура папок и правила
src/
├─ app/
├─ pages/
Слой → слайс → сегмент
Слой — уровень ответственности, слайс — предметная область, сегмент — ui,
model или api.
├─ widgets/
├─ features/
│ └─ auth/ (ui, model, api)
├─ entities/
Public API
Снаружи слайс доступен только через index.ts, внутренности скрыты.
└─ shared/
Контроль
Правила импортов проверяет линтер, например Steiger.
Архитектура приложений · 13 / 20

14.

FSD: на практике
Пример: экран входа по слоям
Экран собирается из слоёв сверху вниз, и каждый слой импортирует только нижние.
pages/login
экран входа
→
features/auth
форма и вход
→
entities/user
модель пользователя
→
shared/api
HTTP-клиент
Что где лежит
Выгода
Форма и логика входа — в features/auth, данные пользователя
— в entities/user.
Фичу можно удалить или переписать, затронув один слайс.
Архитектура приложений · 14 / 20

15.

FSD: оценка
Плюсы, минусы и когда брать
Плюсы
Минусы
Когда брать
Единые правила для команды.
Предсказуемая структура. Фичи
изолированы и легко удаляются.
Порог входа выше. Нужно
договориться, что считать фичей, а что
сущностью. Для маленьких проектов
избыточно.
Средние и крупные фронтенд-проекты,
растущая команда, долгая жизнь
продукта.
Архитектура приложений · 15 / 20

16.

Уровень системы
Монолит и микросервисы
Монолит
Микросервисы
auth
catalog
cart
pay
search
notify
Одно приложение
Один деплой, простая отладка. Без модулей превращается в
ком.
Архитектура приложений · 16 / 20
Независимый деплой и масштаб. Цена — сеть, наблюдаемость,
DevOps.

17.

Микросервисы: на практике
Схема взаимодействия
• У каждого сервиса своя БД
• Связь: REST, gRPC или очередь сообщений
• Gateway — единая точка входа
Для фронтенда аналог — микрофронтенды: независимо собираемые части одного интерфейса.
Архитектура приложений · 17 / 20

18.

Эволюция
Как архитектура растёт вместе с продуктом
Хаос
прототип
→
Слои
появляется структура
→
Модули
растёт команда
→
FSD / Clean
долгая жизнь
Сигналы пора менять
Как мигрировать
Долгий онбординг, страх трогать код, конфликты команды в
одних файлах.
Постепенно: новые фичи пишите по новым правилам, старый
код переносите при правках.
Архитектура приложений · 18 / 20

19.

Сравнение
Подходы в сравнении
Подход
Подходит для
Главный минус
Без архитектуры
прототип, M VP, хакатон
быстро превращается в хаос
Слоистая
типовые C RUD - приложения
логика протекает между слоями
Модульная
средние и большие продукты
сложные границы модулей
M VC / M VP / M V VM
экраны с состоянием UI
не описывает весь проект
C lean / H exag o nal
долгоживущая сложная логика
много слоёв и шаблонного кода
FS D
фронтенд на React, Vue и др.
нужна дисциплина команды
Микросервисы
большие распределённые системы
сеть, D evO ps, сложная отладка
Архитектура приложений · 19 / 20

20.

Итоги
Как выбрать архитектуру
• Начинайте с простого: слои или модули
• Усложняйте, когда появляется боль, а не заранее
• Зафиксируйте правила импортов и проверяйте линтером
• Архитектура — договорённость команды, а не догма
Архитектура приложений · 20 / 20