Архитектура ПО: что это и какие решения в неё входят

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

Мартин Фаулер в колонке «Who Needs an Architect?» (IEEE Software, 2003) разбирает два определения Ральфа Джонсона. Первое: архитектура — это общее понимание устройства системы, которое разделяют ведущие разработчики. Второе: это решения, которые хотелось бы принять правильно в самом начале проекта. Люди хотят принять их рано, потому что считают их трудными для изменения, — отсюда рабочее определение «то, что считают трудным для изменения» и итог Фаулера: архитектура — это про важное, что бы это ни было.

Практичный фильтр дал Майкл Найгард в статье об ADR (2011): архитектурно значимы решения, которые влияют на структуру системы, её нефункциональные характеристики, зависимости, интерфейсы или технику построения.

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

Удобная рамка — пять столпов Azure Well-Architected Framework от Microsoft: надёжность, безопасность, оптимизация затрат, операционное совершенство и эффективность производительности. Рамка написана для облака, но её вопросы подходят любой системе. Добавим шестой атрибут — изменяемость, то есть сколько стоит внести изменение. Фаулер подчёркивает, что высокое внутреннее качество не замедляет, а ускоряет поставку функций: в коде меньше «мусора», который мешает его понять.

Атрибуты качества конфликтуют: улучшая один, почти всегда платишь другим. В Well-Architected Framework у каждого столпа есть отдельная страница компромиссов. Несколько примеров из раздела о производительности:

• Кэш ускоряет ответы, но чем дольше живёт копия, тем вероятнее, что она отражает устаревшее состояние: закэшированное решение об авторизации может пускать пользователя, которого уже заблокировали
• Компоненты ради скорости — шина сообщений, балансировщик, кэш — увеличивают поверхность атаки и стоимость, а их самих тоже нужно делать надёжными
• Шардирование и денормализация ускоряют работу с большими данными, но усложняют согласованность и рутинные операции вроде резервного копирования
• Плотное размещение нескольких приложений на одной платформе экономит ресурсы, но расширяет радиус поражения при сбое

Поэтому фраза «так лучше» в архитектуре звучит подозрительно. Рабочая формулировка — «для нашей нагрузки и нашей команды мы выбираем X ради атрибута A и принимаем цену B». Именно её записывают в ADR, о котором речь ниже.

Модуль — часть системы с одной зоной ответственности и явным публичным интерфейсом. Граница модуля отвечает на вопрос, что снаружи можно использовать, а что является его внутренним устройством. Для сервиса записи естественные модули совпадают с языком бизнеса: «Записи», «Расписание», «Уведомления», «Оплата».

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

Внутри backend-модуля код обычно делят ещё и на слои: контроллер принимает HTTP, сервис держит бизнес-правила, репозиторий работает с базой. Это следующий уровень приближения — его разбирает урок о слоях backend-приложения.

Архитектуру нужно уметь показать: новому разработчику, заказчику, себе через полгода. C4-модель Саймона Брауна предлагает рисовать систему как карту с масштабом — четыре уровня приближения, от общего вида до кода. Модель не зависит от нотации и инструмента: подойдут и маркерная доска, и любой редактор диаграмм.

Сайт c4model.com рекомендует диаграммы контекста и контейнеров всем командам. Диаграмму компонентов советует рисовать, только если она добавляет ценность, а для долгоживущей документации — генерировать автоматически. Диаграмму кода для долгоживущей документации не рекомендует: IDE строит её по запросу. Начнём с контекста сервиса записи.

Уровень контейнеров раскрывает «Сервис онлайн-записи»: из каких запускаемых частей он состоит и как они общаются.

Диаграмма показывает, что построено, но не объясняет почему. Через год новый разработчик увидит монолит и спросит, почему не микросервисы. Майкл Найгард описал два плохих исхода: слепо принять старое решение, не понимая его, или слепо поменять, сломав то, ради чего его принимали. Его ответ — Architecture Decision Record (ADR), короткая запись об одном архитектурном решении и его причинах.

ADR хранят в репозитории рядом с кодом, в Markdown, и нумеруют по порядку; номера не переиспользуют. Объём — одна-две страницы: по словам Найгарда, большие документы никто не читает и никто не обновляет. Формат состоит из пяти частей.

# ADR NNNN: Короткая фраза о решении

## Контекст

Какие силы действуют: требования, ограничения, сроки, команда, нагрузка.
Только факты, без оценок. Какие варианты рассматривали.

## Решение

Что мы делаем. Полные предложения в активном залоге: «Мы будем…».

## Статус

Предложено | Принято | Устарело | Заменено ADR NNNN

## Последствия

Что станет проще и что станет сложнее после решения.
Все последствия, а не только положительные.

# ADR 0002: Модульный монолит для сервиса записи

## Контекст

Сервис онлайн-записи в салоны: клиент выбирает услугу, мастера и время,
администратор видит расписание, клиент получает напоминание в Telegram.
Команда — три разработчика, релиз раз в неделю. Модули «Записи»,
«Расписание», «Уведомления» и «Оплата» выделены, но их границы проверены
только на одном салоне. Запись не должна теряться, если Telegram недоступен.

## Решение

Мы будем развёртывать серверную часть как одно приложение Node.js с одной
базой PostgreSQL; веб-интерфейс на Next.js остаётся отдельным приложением.
Каждый модуль лежит в своей папке, владеет своими таблицами и открывает
другим модулям только публичный интерфейс. Импорт внутренних файлов чужого
модуля запрещает линтер в CI. Напоминания отправляет фоновая задача: запись
сохраняется в базе сразу, отправка повторяется при сбое Telegram.

## Статус

Принято, 2026-10-11. Заменяет ADR 0001 «Отдельный сервис уведомлений».

## Последствия

Одна сборка и одно развёртывание: проще мониторинг, откат и локальный запуск.
Создание записи и бронирование слота остаются одной транзакцией базы данных.

Модули нельзя масштабировать и выпускать по отдельности: исправление в
«Оплате» требует релиза всего приложения. Границы держатся на дисциплине и
проверке импортов; без неё монолит станет «клубком».

Если модулю понадобится своё масштабирование или отдельная команда, мы
вынесем его в сервис и оформим это новым ADR, который заменит этот.

Шаблон Найгарда — не единственный. Каталог на adr.github.io и репозиторий Джоэла Паркера Хендерсона собирают и другие: MADR с явным списком рассмотренных вариантов и их плюсов и минусов, Y-statements — решение в одном структурированном предложении, подробный шаблон Тайри и Акермана. Важнее регулярность, чем выбор шаблона. Писать ADR на каждое решение не нужно: временный обходной путь, прототип или эксперимент с ограниченным риском и ценой документа не требуют.

Архитектуру не утверждают один раз навсегда. Фаулер приводит письмо Джонсона: в программах нет теоретической причины, по которой что-то трудно изменить. Любую отдельную часть можно сделать лёгкой для изменения, но каждая такая часть немного усложняет систему, а если сделать гибким всё, система станет очень сложной — сложность же и делает программы трудными для изменения. Поэтому одна из главных задач архитектора, по Фаулеру, — убирать необратимость там, где она обходится дорого, а не делать гибким всё подряд.

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

Дальше в направлении — принципы, по которым проводят границы внутри кода: SOLID, а затем паттерны проектирования, которые реализуют эти границы на практике.