Архитектура программного обеспечения
Архитектура программного обеспечения — это высокоуровневая структура системы: набор решений о том, из каких компонентов она состоит, как они взаимодействуют и по каким принципам организованы.
Что это
Архитектура программного обеспечения — это совокупность фундаментальных решений о структуре системы: из каких частей она состоит, как эти части общаются между собой и какими принципами руководствуются разработчики при её развитии. Это не код и не документация сама по себе — это набор осознанных компромиссов, которые определяют, насколько легко систему масштабировать, поддерживать и изменять. Хорошая архитектура не видна пользователю, но именно она отвечает за то, что сервис выдерживает миллион запросов в сутки и не ломается при добавлении новой фичи.
Зачем это нужно
Термин закрепился в индустрии в 1990-х: в 1992 году Перри и Вольф опубликовали основополагающую статью, а в 2000 году Рой Филдинг в своей диссертации описал REST как архитектурный стиль — и это изменило, как строится большинство современных API. Без явно выбранной архитектуры проект превращается в «большой комок грязи» (Big Ball of Mud) — антипаттерн, при котором любое изменение ломает что-то непредсказуемое. Архитектурные решения принимаются в начале проекта и дорого обходятся при переработке: переход с монолита на микросервисы в зрелом продукте занимает месяцы и требует остановки части разработки.
Как это работает
Архитектура описывается через несколько измерений. Во-первых, это структурные паттерны — устоявшиеся способы организации системы. Во-вторых, принципы взаимодействия компонентов: синхронные вызовы, очереди сообщений, события. В-третьих, нефункциональные требования — производительность, отказоустойчивость, безопасность, — которые архитектура должна обеспечивать. Архитектор фиксирует решения в Architecture Decision Records (ADR) — коротких документах формата «контекст → решение → последствия», чтобы команда понимала, почему система устроена именно так.
Основные архитектурные паттерны
- Монолит — вся система развёртывается как единое приложение. Просто в старте, сложно масштабировать отдельные части. Типичный выбор для MVP.
- Микросервисы — система разбита на независимые сервисы с собственными базами данных. Каждый деплоится отдельно. Используют Netflix, Uber, Авито.
- Слоистая архитектура (Layered) — код разделён на слои: представление, бизнес-логика, доступ к данным. Классика для корпоративных приложений.
- Событийно-ориентированная архитектура (Event-Driven) — компоненты общаются через события и очереди (Kafka, RabbitMQ). Хорошо работает при высокой нагрузке и слабой связанности.
- Serverless — разработчик пишет функции, инфраструктурой управляет облако (AWS Lambda, Yandex Cloud Functions). Архитектурное решение на уровне деплоя и масштабирования.
Примеры
- Instagram в 2010 году запустился как монолит на Django и PostgreSQL — это позволило быстро выйти на рынок. Переход к более распределённой архитектуре начался после покупки Facebook в 2012-м.
- Amazon в начале 2000-х принудительно перевёл все внутренние системы на сервисно-ориентированную архитектуру (SOA) — это стало основой для AWS.
- Тинькофф Банк использует микросервисную архитектуру: сотни независимых сервисов позволяют командам деплоить изменения несколько раз в день без остановки всей системы.
- Браузер Chrome архитектурно разделяет каждую вкладку на отдельный процесс — это архитектурное решение обеспечивает изоляцию: падение одной вкладки не роняет остальные.
Связанные понятия
- Паттерны проектирования — решения на уровне кода и классов, а не системы в целом (например, Singleton, Observer)
- Технический долг — накопленные архитектурные компромиссы, которые замедляют разработку
- Нефункциональные требования — производительность, масштабируемость, надёжность, которые архитектура должна обеспечивать
- DevOps и CI/CD — практики, которые влияют на архитектурные решения: микросервисы требуют зрелого CI/CD-пайплайна
- Domain-Driven Design (DDD) — подход к проектированию, при котором архитектура отражает структуру бизнес-домена
Частые заблуждения
Главный миф: микросервисы лучше монолита по умолчанию. Это не так — микросервисы решают проблемы масштабирования команды и нагрузки, но добавляют сложность сети, мониторинга и согласованности данных. Для команды из трёх человек это чаще вред, чем польза. Второй миф: архитектуру можно спроектировать один раз и не трогать. На практике архитектура эволюционирует вместе с продуктом — и это нормально. Задача архитектора не зафиксировать идеальную схему, а принимать решения, которые оставляют пространство для изменений.