«Software architecture is like an elephant: no one person can see the whole thing.» Генри Буч
Архитектура программного обеспечения — это фундамент системы, подобно тому как архитектура здания определяет его прочность, функциональность и возможность развития. Но программная архитектура — это не просто схема компонентов. Это совокупность инженерных решений о том, из чего состоит система, как организованы ее части и как они взаимодействуют между собой. Именно эти решения определяют, сможет ли система выдерживать рост нагрузки, изменение требований и развитие в течение многих лет. Ошибку в коде можно исправить за часы, а ошибочное архитектурное решение может привести к перестройке всей системы. Поэтому архитектура — это одна из ключевых инженерных задач программной инженерии.
Понятие архитектура программного обеспечения
Архитектура ПО — это фундаментальная организация программной системы, включающая:
- основные структурные элементы;
- связи между ними;
- принципы проектирования и развития системы;
- решения, имеющие долгосрочное влияние на систему.
Архитектурное представление:

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

Архитектурные стили
Основные элементы архитектуры
- компоненты;
- подсистемы;
- интерфейсы;
- зависимости;
- потоки данных;
- взаимодействия между элементами.
Архитектурный стиль — это типовая организация компонентов и их взаимодействия.

многослойная архитектура:

клиент–сервер:

микросервисная архитектура:

событийно-ориентированная архитектура:

конвейер (Pipe-and-Filter):

MVC:

Архитектурные техники
это единичное проектное решение, влияющее на контроль одного конкретного атрибута качества
| Внедряемая тактика (Плюс) | Целевое качество | Побочный эффект (Минус) | Пострадавшее качество | Обоснование компромисса |
|---|---|---|---|---|
| Шифрование данных (Encryption) | Безопасность | Дополнительные циклы CPU на кодирование/декодирование | Производительность | Процессор тратит время на математические вычисления вместо обработки бизнес-логики. |
| Избыточность (Redundancy) | Надежность | Необходимость синхронизации данных между серверами | Производительность & Сложность | Падает скорость записи, так как нужно дождаться подтверждения от всех резервных узлов. |
| Кэширование результатов (Caching) | Производительность | Риск отдать пользователю устаревшие (протухшие) данные | Согласованность данных | Требуется сложная логика инвалидации кэша, что увеличивает вероятность ошибок. |
| Слабое зацепление (Loose Coupling) | Модифицируемость | Появление сетевых прослоек (API, брокеры сообщений) | Производительность | Вместо быстрого вызова функции в памяти происходит долгий сетевой запрос (Network Overhead). |
| Микросервисная декомпозиция | Масштабируемость | Распределенная система вместо монолита | Тестируемость & Отладка | Сложнее воспроизвести баг локально, так как цепочка вызовов проходит через десятки сервисов. |
Оценка архитектуры
Оценка архитектуры по SWEBOK — это процесс верификации проектных решений до или в процессе написания кода. Ее цель — убедиться, что выбранная структура способна удовлетворить критические атрибуты качества (нефункциональные требования) и бизнес-цели.
Архитектурные представления (Views)
Для разных заинтересованных сторон используются разные представления архитектуры.

Архитектура фиксируется в виде:
- UML-диаграмм компонентов и диаграмм развертывания;
- описаний решений;
- архитектурных спецификаций.
Документация должна быть понятной разработчикам и другим заинтересованным сторонам.