Слои в клиентском приложении

‼️Идеального решения не существует. Руководствуйтесь здравым смыслом.

Ранее мы уже говорили о том, что в приложении с React часто происходит замешивание слоев, но не обсуждали, зачем вообще выделять слои и какие чаще всего выделяют.

Начнем с вопроса «Зачем?»

🔹 1. Легче поддерживать код
Попробуйте сделать простое упражнение на вашем проекте — посчитайте количество задач на полностью новую функциональность и на доработки/развитие/"любое-другое-взаимодействие" с уже написанным кодом.
Предположу, что у большинства вторая группа будет больше. Деление на слои позволяет сделать поддержку сильно проще и сэкономит вам много нервных клеток.
- Если каждый слой отвечает только за свою задачу, менять что-то в бизнес-правилах, API или в UI можно независимо друг от друга.
- Меньше шансов «сломать что-то другое», когда вносятся доработки.

🔹 2. Проще тестировать
Тестируемость вашего кода — крайне важный критерий.
Чаще всего, если вам сложно тестировать код, то, скорее всего, вы где-то свернули не туда.
- Бизнес-логику можно тестировать отдельными юнит-тестами без запуска браузера и без реальных API.
- API-функции легко мокать, не мешая бизнес-функциям.
- UI можно тестировать отдельно, не беспокоясь о внутренней кухне данных.

🔹 3. Повышается переиспользуемость
Переиспользуемость кода — один из ключевых критериев хорошей архитектуры.
При верном разделении на слои вам будет проще переиспользовать ваши решения.
- Бизнес-логику можно легко переиспользовать: десктопный-веб, мобильный-веб, да даже другой проект.
- Более чистая логика проще адаптируется к изменениям, например, при смене API: в слое API меняются адреса/структуры, а бизнес-логика не трогается.

🔹 4. Уменьшается связанность компонентов
Тот самый coupling, о котором вы, скорее всего, услышите из любого рассказа про архитектуру.
Чем меньше связанность, тем проще поддерживать и изменять код, переиспользовать решения и т. д.
- Компоненты не знают, как именно приходят/сохраняются данные, они просто «получают props».
- Если меняется источник данных (например, из REST на GraphQL), UI не нужно переписывать вовсе.

🔹 5. Управляем сложностью
Многие концентрируются только на технической стороне вопроса, но объем когнитивной нагрузки на разработчика тоже очень важен.
Когда-то давно читал, что по когнитивной нагрузке разработчик ближе всего к нейрохирургу, так как оба работают с очень сложными системами.
А чем больше когнитивная нагрузка, тем быстрее вы устаете, повышается порог входа и т. д.
- Чем больше приложение, тем легче «потеряться» в взаимосвязях.
- Слои разбивают проект на удобные, изолированные части. Держать отдельную часть в голове проще, чем целый проект.
- Проще объяснить проект новичку: «здесь правила бизнеса, здесь — работа с API, здесь — хранилище, а вот UI». Следовать уменьшается проблема Bus Factor`а.

🔹 6. Облегчается командная разработка
Уверен, что все вы сталкивались с конфликтами при мердже, и у каждого был какой-то очень заковыристый конфликт, после которого, скорее всего, были багули и т. д.
Один, может быть, и воин, но не в разработке точно, поэтому крайне важно, чтобы над проектом УДОБНО И БЕЗОПАСНО МОГЛИ работать сразу несколько разработчиков.
Разделение на слои позволяет чаще взаимодействовать на уровне интерфейсов, а не реализаций, что позволяет реже конфликтовать с другими изменениями.
- Чёткое разделение зон ответственности.
- Комфортнее параллельная работа.
- Легче делать code review.
- Безопасность и независимость изменений.

🔹 7. Легче менять технологии
Никогда не говори никогда. Скорее всего, вы не часто меняете React на Vue и что-то подобное, но вот более маленькие библиотеки меняются чаще.
Уверен, что многие точно сталкивались с переходом с одного стейта-менеджера на другой и т. д. Деление на слои позволяет вам не переписывать весь проект при такой замене, а ограничиться только одним слоем (чаще всего).
- Хочется переписать UI на другую библиотеку — все бизнес-правила и API-клиенты уже вынесены и остаются прежними.

Конечно, это не все. Дальше обсудим подробнее.