Где начинается архитектура?
Часто под архитектурой подразумевают нечто крупное: диаграммы, сервисы, базы, очереди. Но это лишь один из уровней. На самом деле архитектура пронизывает всё: от названия переменной до устройства экосистемы из сотен сервисов.
Уровень 1: переменная Если ты называешь переменную data, tmp или того хуже a, b, ты вносишь неопределённость. Это снижает предсказуемость, повышает когнитивную нагрузку, увеличивает шанс ошибки. Даже такие мелочи могут иметь архитектурные последствия.
Уровень 2: функция Функция, которая делает несколько вещей, — антипаттерн, антиархитектура. Плохая декомпозиция = невозможность покрыть тестами, переиспользовать, локализовать баг. А потом эту функцию копируют, и дефект масштабируется. Это уже "вирусная" архитектура. Чистая функция — там, где это возможно — хорошее правило.
Уровень 3: модуль (или класс) Где границы? Что знает о внешнем мире? Где side-effect, где чистая логика? Если всё перемешано — модуль становится токсичным. Появляется архитектурный долг. Про SOLID можно вспомнить, но слепо следовать — не стоит. Это не закон, а инструмент.
Уровень 4: приложение Здесь начинается архитектура, о которой все говорят: деплой, отказоустойчивость, масштабирование. И здесь же локальные решения начинают конфликтовать между собой.
Вопросы:
- Где entry point и как устроен lifecycle?
- Разделены ли core и инфраструктура?
- API отделён от логики?
- Есть ли единый контейнер зависимостей?
- Поддерживается ли graceful shutdown?
- Что происходит под нагрузкой?
Если у тебя всё завязано на index.mjs — это скрипт, не система. Если каждый модуль сам себе открывает базу — ты не управляешь ничем.
Уровень 5: сервисы и экосистема Здесь архитектура становится явной. Ты больше не один. Каждый модуль, каждая точка отказа — это чья-то зона ответственности.
Вопросы:
- Как сервисы общаются? Протоколы, форматы, контракты.
- Кто владеет данными и отвечает за консистентность?
- Что делать при недоступности одного из сервисов?
- Как живут запросы, проходящие через 3–5 сервисов?
- Есть ли ретраи, деградация, алерты?
Если сервис лезет в чужую базу — это не архитектура, а хаос. Если один отказ тянет каскад — это не система, это стек домино.
Принцип Архитектура — не про масштаб, а про осознанность. Каждое локальное решение влияет на уровень выше. Если ты не проектируешь явно — ты проектируешь по умолчанию. И, скорее всего, плохо.
Вывод Архитектура начинается не на доске. Она начинается с вопросов:
А можно ли тут сделать чистую функцию? А читаемый ли код? А если это упадёт — что произойдёт?
Если ты задаёшь эти вопросы — ты уже в процессе. Если нет — никакие блок-схемы не помогут.
И да: плохое имя переменной может быть началом деградации. Так же как чёткое понимание точек отказа — началом зрелости.
