Основы системного дизайна
Архитектура ПО: основные понятия
1. Проблема и зачем это нужно
Код живёт и работает, но через полтора года в него страшно заходить: каждый новый функционал ломает два старых, разбор одного отчёта требует шести человек и двух выходных, а под нагрузкой сервис «думает» по 4 секунды. Знакомое состояние «код работал — теперь переписываем».
Причина почти всегда одна — у системы нет архитектуры. Есть набор кода, который случайно сложился в приложение. Архитектура ПО отвечает на вопрос «из чего состоит приложение, как его части взаимодействуют и как это менять без боли».
Для владельца бизнеса разница ощутима в деньгах и сроках. Хорошая архитектура — это скорость добавления фич и управляемый риск поломки. Плохая — рост стоимости каждого изменения и накопление «технического долга», который однажды оплачивается полностью, с процентами.
2. Что это и как работает
Архитектура программного обеспечения — принципиальная структура системы: набор компонентов, их обязанности и отношения между ними. Она отвечает не на «какая функция», а на «какая часть за что отвечает и кто с кем разговаривает».
Три уровня, которые обычно имеет в виду архитектор:
- Структура приложения. Монолит, сервисы, слои (интерфейс, логика, данные).
- Взаимодействие. Как компоненты обмениваются данными: синхронные вызовы, очереди, сообщения.
- Окружение. Где всё это живёт: сервера, база, сеть, СХД, и как они связаны.
Базовая схема трёхслойного приложения выглядит так: *клиент → приложение → база данных*. Каждый слой изолирован и отвечает за своё. Интерфейс только показывает, приложение только считает и проверяет, база только хранит. Разделение обязанностей — основа, на которой держится любая архитектура, от монолита до микросервисов.
Разобраться, где проходит граница между монолитом и микросервисным решением, полезно до глубокого проектирования. Критерии выбора — в материале микросервисы против монолита.
3. Основные понятия и термины
- Монолит — приложение собрано в один процесс, все функции в одной кодовой базе.
- Микросервис — автономный сервис, решающий одну задачу и общающийся через API.
- Слоистая архитектура — разделение на слои: представление, бизнес-логика, доступ к данным.
- API — контракт, по которому системы обмениваются данными и вызывают функции друг друга.
- Событие / очередь — асинхронная передача «сообщить, что произошло», не блокируя основную работу.
- БД и репозиторий — уровень данных: какая база выбрана и как с ней работает приложение.
- Связанность (coupling) — насколько компоненты зависят друг от друга; чем меньше связь, тем легче менять.
- Технический долг — цена отложенных улучшений, накапливаемая при быстрых правках без архитектуры.
4. Плюсы и минусы продуманной архитектуры
| Плюс | Минус | Противовес / решение |
|---|---|---|
| Быстрое добавление новых фич | Проектирование занимает время на старте | Выделять архитектурный этап один раз, дальше экономия |
| Меньше поломок при изменениях | Нужна дисциплина и правила у команды | Код-ревью, автотесты, регламент на изменения |
| Понятный язык для закупки и ТЗ | Требует описания в документах | Фиксировать архитектуру в ADR — записях о решениях |
| Возможность роста нагрузки | Чем больше слоёв, тем больше точек отказа | Резервировать и балансировать только критичный путь |
Типовая ловушка — переусложнить. Добавить очереди, шины данных и kafka там, где хватает монолита на 40 человек. Стоимость владения сложной архитектуры растёт быстро, а выгода видна только после определённого размера. Поэтому выбор архитектуры всегда взвешивается против текущей и будущей нагрузки.
5. Типовые ошибки в архитектуре ПО
| Ошибка | Причина | Решение |
|---|---|---|
| Дробить на микросервисы «для красоты» | Модное слово вместо границ | Чёткая постановка: под конкретную нагрузку и команду |
| Игнорировать «технический долг» | Быстрое закрытие фич без рефакторинга | Выделять время на улучшение кода в спринтах |
| Не фиксировать контракты между компонентами | «Точно работает, не трогай» | Описывать интерфейсы и менять только по согласованию |
| Выносить состояние на несколько сервисов | Сломать жёсткую связь попытками | Удерживать данные в границах одного модуля |
| Строить архитектуру без схемы и ADR | Теряется причина принятого решения | Вести записи о решениях и актуальную схему |
| Подбирать железо «понадёжнее» к слою | Отрыв архитектуры от ресурсов | Считать нагрузку и ёмкость под каждый слой |
При проектировании под госзаказчика добавьте сюда документацию. Хорошая архитектура без описания нечасто проходит согласование: ТЗ, схема взаимодействия и обоснование состава — обязательный минимум для 44-ФЗ/223-ФЗ. Как правильно оформить требования, рассказано в ТЗ на ИТ-инфраструктуру.
6. Как это сделать в вашей организации
- Опишите текущую структуру. Схематично нарисуйте, кто с кем разговаривает и где хранятся данные. Уже на этом шаге всплывают лишние связи.
- Определите границы. Какая часть системы отвечает за конкретный функционал и может меняться независимо.
- Зафиксируйте интерфейсы. Контракты между компонентами — то, что нельзя менять без согласования.
- Выберите модель данных. Реляционная база, объектное хранилище, кэш — под тип и объём нагрузки. Подсказка для выбора — шардирование и кэширование.
- Опишите железо под архитектуру. Каждому слою — свои требования по мощности. Под ответственные узлы смотрите серверы в каталоге и системы хранения данных.
Архитектура не застывает. Она меняется, когда нагрузка растёт — тогда подключается масштабирование и балансировка.
7. Вопросы и ответы
Архитектура ПО — это про код или про железо? — Про оба уровня. Архитектура описывает устройство приложения и его окружение, а железо под это окружение подбирается расчётом по нагрузке.
Когда пора задумываться об архитектуре? — Не по строке кода, а по первому признаку «правка одной фичи ломает другую». Это сигнал переусложнить или не структурировать.
Микросервисы всегда лучше монолита? — Нет. Микросервисы окупаются при большой команде и высокой нагрузке. Для большинства задач монолит проще, дешевле и надёжнее.
Обязательно ли документировать архитектуру? — Да, хотя бы записи о ключевых решениях (ADR). Иначе решение принимает тот, кто «раньше тут работал», и уходит вместе с ним.
Частые вопросы
Архитектура ПО — это про код или про железо?
Про оба уровня. Архитектура описывает устройство приложения и его окружение, а железо под это окружение подбирается расчётом по нагрузке.
Когда пора задумываться об архитектуре?
Не по строке кода, а по первому признаку «правка одной фичи ломает другую». Это сигнал переусложнить или не структурировать.
Микросервисы всегда лучше монолита?
Нет. Микросервисы окупаются при большой команде и высокой нагрузке. Для большинства задач монолит проще, дешевле и надёжнее.
Обязательно ли документировать архитектуру?
Да, хотя бы записи о ключевых решениях (ADR). Иначе решение принимает тот, кто «раньше тут работал», и уходит вместе с ним.