Что такое архитектура программного обеспечения

Что мы понимаем под архитектурой

Если подойти к определению архитектуры интуитивно, первое, что приходит в голову — архитектура это структура системы. Такое сравнение вполне логично: архитектура дома описывает его конструкцию и фундамент, то, на чём держится всё остальное. Аналогично, архитектура программного продукта определяет основу, на которой строится всё остальное приложение.

Это определение верно, но сразу рождает новый вопрос:

Что именно считается «структурой системы» и как её определить — будь то фронтенд или бэкенд?

Ответить на это не так просто. Даже опытные архитекторы расходятся во мнениях. В качестве иллюстрации я приведу историю, описанную Мартином Фаулером более 20 лет назад.

Когда Фаулер писал книгу, в названии которой фигурировало слово Architecture, он почувствовал, что обязан дать чёткое определение термина. В поисках ответа он обсудил это с Ральфом Джонсоном, одним из авторов знаменитой книги Design Patterns.

Во время разговора они рассматривали разные варианты, и один из них звучал так:

Архитектура — это решения, которые вы хотели бы принять правильно как можно раньше.

Это определение подчёркивает, что архитектура — это набор решений, особенно тех, которые потом будет трудно изменить. Именно эти ранние решения формируют «каркас» системы и влияют на всё последующее развитие.

Из этого следует:

Всё, что в системе трудно изменить, можно считать частью архитектуры.

Но и здесь остаётся вопрос: как определить, что именно трудно изменить?

Продолжая обсуждение, Фаулер и Джонсон пришли к ещё одной формулировке:

Архитектура — это важные вещи. Какие именно — решать вам.

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

Более точное определение

Для целей этого курса мы используем формулировку из книги Michael Keeling — “Design It!” Эта книга во многом определяет структуру нашего курса, потому что её подход объединяет понимание проблемы, проектирование и принятие решений.

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

Разбираем определение по частям

1. Архитектура — это набор решений.
   Это согласуется с предыдущими определениями. Архитектура — не просто чертёж или схема. Это совокупность решений, которые формируют систему.
2. Эти решения значимы.
   Они касаются вещей, которые сложно или дорого менять. Именно поэтому их нужно принимать осознанно и фиксировать (например, в виде ADR — Architecture Decision Record).
3. Архитектура определяет организацию системы.
   Здесь возвращаемся к идее структуры. Архитектура задаёт принципы, по которым мы структурируем код, модули, компоненты и связи между ними.
4. Цель архитектуры — обеспечение качественных атрибутов.
   Эти атрибуты — то, что делает систему полезной и устойчивой. Примеры:
   • производительность,
   • масштабируемость,
   • доступность,
   • удобство развертывания,
   • наблюдаемость,
   • удобство сопровождения.

Все эти характеристики — «важные вещи», ради которых архитектура вообще существует.

Четыре измерения архитектуры

Чтобы понять, как выглядит архитектура на практике, полезно использовать модель из книги “Head First Software Architecture” (Mark Richards и Neal Ford).

Авторы предлагают рассматривать архитектуру в четырёх измерениях:

1. Архитектурный стиль (Architectural Style)
2. Характеристики системы (Quality Attributes / Characteristics)
3. Архитектурные решения (Architectural Decisions)
4. Логические компоненты (Logical Components)

Метафора: персонаж видеоигры 🎮

Чтобы проще запомнить эти четыре измерения, представим архитектуру как персонажа из ролевой игры.

1. Класс персонажа → Архитектурный стиль
   Например: микросервисы, монолит, событийная архитектура, слоистая модель.
   Класс определяет «форму» и общий облик архитектуры — её основу и принципы.
2. Характеристики (статы) → Качественные атрибуты
   Как у персонажа есть сила, ловкость и скорость, так и у архитектуры есть свои характеристики:
   производительность, надёжность, масштабируемость, гибкость, скорость деплоя и т. д.
   Нельзя быть «сильным во всём» — всегда приходится расставлять приоритеты.
3. Предыстория → Архитектурные решения
   Это история выбора: какие технологии, протоколы, соглашения и ограничения были приняты.
   Например, в микросервисной архитектуре — решение о способах коммуникации между сервисами, выборе протокола, формате обмена и правилах взаимодействия.
   Всё это должно быть зафиксировано и обосновано (в ADR).
4. Навыки → Логические компоненты
   Это конкретные строительные блоки — модули, классы, UI-компоненты, библиотеки, функции.
   Именно они делают архитектуру «живой» и функциональной.

Почему важно учитывать все четыре измерения

Чтобы описать архитектуру полноценно, нужно смотреть на все четыре аспекта сразу. Если рассматривать только стиль или только код — мы видим лишь часть картины.

Эта модель универсальна: она подходит для любой системы, будь то сервер, фронтенд или микросервис. Поэтому, говоря о фронтенд-архитектуре, мы можем использовать те же самые принципы — и именно это мы сделаем в следующем уроке.

🧩 Краткое резюме

• Архитектура — это набор решений, а не просто схема.
• Эти решения важны, потому что их трудно изменить.
• Архитектура помогает достичь нужных качественных характеристик системы.
• Она проявляется в четырёх измерениях: стиль, характеристики, решения и компоненты.
• И наконец, архитектура — это «важные вещи», которые делают систему устойчивой и понятной.