Что такое архитектура на самом деле

Определение через стоимость изменения

Самое полезное определение программной архитектуры — не про диаграммы со стрелочками и не про именованные паттерны. Ральф Джонсон сформулировал просто: архитектура — это решения, которые сложно изменить. Мартин Фаулер уточнил: решения, которые стоят всё дороже и дороже менять по мере того, как система растёт вокруг них.

Эта формулировка сразу отделяет архитектуру от обычного дизайна. Если сегодня выбрал имя переменной, а завтра захотел лучше — rename-рефактор занимает двадцать секунд. Это дизайн — низкая стоимость возврата. Если вложил логику billing прямо в HTTP-обработчик, а через двенадцать месяцев хочешь вызывать тот же billing из фонового задания, мобильного приложения и партнёрского API — это структурная проблема, которая потребует недель рискованной хирургии. Это архитектура — решение с высокой стоимостью возврата.

Вывод неудобный: ты принимаешь архитектурные решения постоянно, независимо от того, называешь ли ты их так. Вопрос не в том, принимать ли их, а в том, принимать ли их намеренно.

Дизайн vs архитектура: два разных горизонта

Дизайн и архитектура — не два уровня иерархии; они работают на разных временных горизонтах и с разными конвертами стоимости.

Дизайн — это форма решения внутри уже установленного структурного контекста. Какой класс содержит этот метод? Как назвать эту функцию? Как должен выглядеть API этого модуля? Эти выборы важны для читаемости и корректности, но их можно пересмотреть без структурной хирургии. Дизайн-решения живут внутри границ, которые нарисовала архитектура.

Архитектура рисует эти границы. Где проходит граница между доменом billing и доменом shipping? Владеет ли каждый домен своей схемой БД, или они используют общую? Может ли сервис заказов обращаться к сервису биллинга синхронно, или это должно идти через событие? Эти решения распространяются структурно — они ограничивают каждое дизайн-решение, принятое после них.

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

Категориальная ошибка «best practice»

«Используй микросервисы» — это best practice. «Используй hexagonal architecture» — best practice. «Отдели бизнес-логику от инфраструктуры» — best practice. Эти предписания появляются в книгах, докладах и инженерных блогах, и они не ошибочны — они описывают паттерны, решавшие реальные проблемы в конкретных командах в конкретных контекстах. Ошибка — трактовать предписание как контекстно-независимое.

Best practices — это решения для конкретных сил. Паттерн hexagonal architecture существует потому, что силы «мне нужно тестировать бизнес-логику без базы данных» и «мне нужно запускать одно и то же приложение из HTTP-сервера, CLI и очереди сообщений» оказывают реальное давление. Если эти силы присутствуют в твоей системе, hexagonal architecture хорошо подходит. Если твоя система — это CRUD API, на которую эти силы никогда не будут давить, hexagonal architecture добавляет слои, интерфейсы и indirection без соответствующей пользы. Это не «best» для тебя — это overkill.

Правильный вопрос никогда не «что является best practice?». Он — «каким силам подвержена моя система, и какие структуры отвечают этим силам?». Это рамка, которую использует весь остальной трек. Каждый рассматриваемый паттерн будет представлен как ответ на поимённый набор сил — и компромиссы, которые он при этом делает.

Чем архитектура не является

Две вещи часто маскируются под архитектуру:

Диаграммы. Диаграмма описывает архитектуру — она не является архитектурой. Команды часто путают артефакт с реальностью. Архитектура — это фактическая структура связанности в кодовой базе; диаграмма — модель этой структуры. Когда диаграмма говорит «billing — отдельный сервис», а код разделяет схему БД с ordering, диаграмма неверна, а связность — реальность.

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