Архитектура - это про ограничения

Когда говорят об архитектуре, обычно думают о том, как что-то построить. Но на самом деле хорошая архитектура - это прежде всего про то, что нельзя делать. Микросервисы? Ограничение: нельзя просто так дёрнуть данные из другого сервиса через ORM. Событийная архитектура? Ограничение: нельзя получить ответ синхронно. Hexagonal architecture? Ограничение: нельзя импортировать инфраструктурный код в бизнес-логику.

Каждое архитектурное решение - это стена, которую мы ставим сами себе.

Потому что без ограничений начинается анархия. Разработчик под дедлайном (как это часто было у меня) выберет самый быстрый путь, не самый правильный. Через год кодовая база превращается в спагетти, где всё зависит от всего, а рефакторинг одной функции ломает три несвязанных модуля. Ограничения заставляют думать.  - Когда мы не можем просто написать user.orders.products, приходится проектировать API.  - Когда не можем хранить состояние в памяти, проектируем персистентность.  - Когда не можем делать синхронные вызовы, начинаем думать о консистентности данных по-взрослому. (Тут можно вообще отдельный пост написать)

В идеале: Хорошая архитектура делает неправильные решения неудобными, а правильные - очевидными.

Но есть нюанс: ограничения должны быть оправданными. Перегрузить проект архитектурными паттернами "на всякий случай" - это как надеть на себя смирительную рубашку перед пробежкой.  Каждое ограничение должно решать реальную проблему, а не существовать ради красоты диаграмм. (как в продолжение моего поста "Я был адептом чистой архитектуры")

Поэтому тут важно ощущать баланс: Слишком мало ограничений - хаос.  Слишком много - паралич.

18/100 Telegram