tzlab.pro

Архитектура: что это и как я принимаю решения

1. Архитектура — это карта системы

Представьте, что вы строите город.

Архитектура — это не отдельные здания. Это план улиц, расположение кварталов, транспортные развязки, коммуникации. Это то, как части города соединены друг с другом.

В IT архитектура — это:

• Как устроены данные.
• Как они двигаются между системами.
• Как модули общаются друг с другом.
• Как система справляется с нагрузкой.
• Как она масштабируется.

2. Монолит vs Микросервисы

Я не спрашиваю: «Что выберем?». Я смотрю на проект и принимаю решение.

Когда я выбираю монолит

Я выбираю монолит, когда:

• Проект небольшой — до 3–5 разработчиков.
• Вы запускаете MVP и вам важна скорость.
• Нагрузка предсказуема и не требует разделения.
• У команды нет опыта с распределёнными системами.
• Вы не планируете масштабировать отдельные части системы.

Когда я выбираю микросервисы

Я выбираю микросервисы, когда:

• Проект крупный — 10+ разработчиков, 5+ модулей.
• Нагрузка неравномерная — один модуль нагружен сильно, другие почти не используются.
• Вы планируете развивать систему годами.
• У команды есть опыт с распределёнными системами.
• Части системы должны обновляться независимо.

3. Фреймворк vs Своя разработка

Это решение я тоже принимаю сам. На основе задачи, горизонта планирования и команды.

Когда я выбираю фреймворк

Я выбираю фреймворк, когда:

• Проект типовой — интернет-магазин, CRM, личный кабинет.
• У команды нет опыта создания архитектуры «с нуля».
• Вы хотите запустить MVP быстро.
• Горизонт планирования — 3–5 лет.

Когда я выбираю свою разработку

Я выбираю свою разработку, когда:

• У вас уникальная предметная область, которую фреймворк не покрывает.
• Вы планируете развивать систему 5+ лет.
• Фреймворк не даёт нужной гибкости или производительности.
• У вас есть опытный архитектор (или я выступаю в этой роли).
• Вы готовы вложить время в создание фундамента.

Что я вижу в крупных компаниях

Когда система живёт 5, 10, 15 лет — фреймворк становится проблемой. Он устаревает, его перестают поддерживать, на нём сложно найти разработчиков, он ограничивает архитектуру.

Крупные компании пишут свои решения. Не потому что им «так хочется», а потому что это единственный способ сохранить контроль над системой в долгосрочной перспективе.

4. Фреймворки приходят и уходят — это факт

Zend был популярен → устарел.
Symfony был популярен → устаревает.
Laravel популярен сейчас → устареет через пару лет.
Yii был популярен → уже не модно.
React, Vue, Angular — те же истории.

Я это учитываю при выборе.

Фреймворки используют для скорости, не понимая, что завтра фреймворк устареет. Появится новый «модный» вариант, и у вас будет два пути:

• Искать разработчиков, которые пишут на старом фреймворке (их становится всё меньше, они всё дороже).
• Переписывать всё на новый «модный» фреймворк (дорого, долго, рискованно).

5. Мои принципы выбора

6. Почему я принимаю решения сам

Потому что бизнес не должен выбирать архитектуру. Бизнес должен формулировать задачи.

• Бизнес говорит: «Нам нужно, чтобы система работала, развивалась и не ломалась».
• Я говорю: «Вот как мы это сделаем. Вот почему. Вот сколько это будет стоить».

7. Итог

Архитектура — это не «модное слово». Это выбор, который определяет будущее вашей системы.

• Монолит — просто и дёшево сейчас, сложно и дорого потом (если проект растёт).
• Микросервисы — сложно и дорого сейчас, просто и гибко потом (если проект растёт).
• Фреймворк — быстро сейчас, дорого потом.
• Своя разработка — дорого сейчас, дёшево потом.