Откройте любой новый проект на GitHub.
Скорее всего, вы увидите знакомую картину: папки Domain, Application, Infrastructure, Presentation, десятки интерфейсов, фабрик, сервисов, репозиториев и других элементов «правильной» архитектуры.
Проект выглядит солидно.
Создается впечатление, что он хорошо спроектирован.
Но внешний вид структуры каталогов почти ничего не говорит о качестве архитектуры.
Потому что архитектура — это не папки.
И даже не паттерны.
Архитектура — это набор решений
Когда говорят об архитектуре, чаще всего обсуждают её форму.
Монолит или микросервисы.
MVC или Clean Architecture.
DDD или CRUD.
Но настоящая архитектура начинается гораздо раньше.
Она отвечает на вопросы:
- Где будут храниться данные?
- Что произойдет, если сервис станет недоступен?
- Как система будет масштабироваться?
- Можно ли заменить одну технологию без переписывания половины проекта?
- Что станет самым слабым местом через год?
- Какие компромиссы мы готовы принять?
Именно ответы на эти вопросы определяют архитектуру системы.
А не расположение файлов.
Папки не решают проблемы
Иногда кажется, что стоит разложить код по красивым директориям — и проект автоматически станет качественным.
Но если бизнес-логика по-прежнему зависит от конкретной базы данных, сервисы тесно связаны друг с другом, а изменение одной функции требует правок в десяти местах, никакая структура каталогов этого не исправит.
Красивое дерево файлов не делает систему гибкой.
Оно лишь делает её красивой.
Паттерны — это инструменты, а не цель
Паттерны проектирования существуют не для того, чтобы использовать их в каждом проекте.
Они помогают решить конкретные задачи.
Но иногда происходит обратное.
Разработчик знает несколько популярных паттернов и начинает искать, куда их можно применить.
В результате появляются:
- фабрики для создания одного объекта;
- репозитории, которые просто повторяют методы ORM;
- интерфейсы с единственной реализацией;
- слои, через которые данные проходят без каких-либо изменений.
Каждый такой элемент увеличивает сложность проекта.
Хотя никакой новой пользы не приносит.
Паттерн становится оправданным только тогда, когда устраняет реальную проблему.
Хорошая архитектура почти незаметна
Есть интересный парадокс.
Если архитектура действительно хорошая, разработчики редко говорят о ней.
Потому что всё работает естественно.
Новые функции добавляются без боли.
Код легко читать.
Изменения не требуют переписывать половину проекта.
Никто не вспоминает об архитектуре каждый день.
Её замечают только тогда, когда она начинает мешать.
Архитектура — это управление зависимостями
Практически любая большая система со временем усложняется.
Полностью избежать этого невозможно.
Но можно управлять тем, где возникает сложность.
Например:
Если заменить базу данных невозможно без переписывания всего проекта — это архитектурное решение.
Если бизнес-логика напрямую зависит от HTTP-запросов — это архитектурное решение.
Если изменение одной сущности требует обновления десятков сервисов — это тоже архитектурное решение.
Архитектура определяет не то, как выглядит код.
Она определяет, насколько дорого его менять.
Самая важная часть архитектуры — компромиссы
Не существует идеальной архитектуры.
Монолит проще разрабатывать.
Микросервисы проще масштабировать независимо.
Кеширование ускоряет систему, но усложняет согласованность данных.
Очереди повышают отказоустойчивость, но делают обработку асинхронной.
Любое решение что-то улучшает и одновременно что-то усложняет.
Архитектор не ищет идеальный вариант.
Он выбирает компромисс, который лучше всего подходит для текущей задачи.
Архитектура меняется вместе с продуктом
Распространенная ошибка — пытаться сразу построить систему, которая выдержит миллионы пользователей.
Большинство проектов до этого никогда не доходят.
Зато все получают сложную архитектуру уже на первом этапе.
Хорошая архитектура развивается вместе с продуктом.
Сначала она решает сегодняшние задачи.
Потом меняется, когда появляются новые требования.
Попытка заранее предусмотреть всё обычно приводит лишь к тому, что проект становится сложнее раньше времени.
Лучшее архитектурное решение иногда звучит как «ничего не менять»
Инженерам нравится создавать новые системы.
Но зрелый опыт часто приводит к противоположному выводу.
Не каждый сервис стоит выносить отдельно.
Не каждую функцию нужно делать универсальной.
Не каждая зависимость оправдана.
Иногда лучшим архитектурным решением оказывается оставить систему такой, какая она есть.
Если она решает текущие задачи без лишней сложности, это уже хороший результат.
Итог
Архитектура — это не диаграммы.
Не папки.
Не набор популярных паттернов.
И даже не выбор фреймворка.
Архитектура — это совокупность решений, которые определяют, насколько легко систему можно развивать, изменять и поддерживать.
Красивую структуру каталогов можно создать за один вечер.
Хорошую архитектуру приходится строить годами.
И её качество становится заметно не в момент первого релиза, а тогда, когда проект переживает десятки изменений и при этом не начинает разваливаться.
Добавить комментарий