Начну с занудства, но важного: это не свежая новость. Software Architecture Guide на сайте Мартина Фаулера датирован 1 августа 2019 года, и самая новая статья внутри него — март 2024-го. Никакого «Фаулер только что обновил главный гид» не было. Зато есть кое-что поинтереснее новостного повода: набор идей, который не устарел за шесть лет именно потому, что написан на уровне принципов, а не технологий. И вот это стоит перечитать — особенно сейчас, когда код стало писать дёшево, а архитектурно думать — дороже. Давайте разберём, что там реально ценного, и где даже у Фаулера тонко.
🧩 Что такое архитектура: определение, которое отказывается быть определением
Самое полезное в гиде — то, как Фаулер отказывается от пафосной трактовки. И ключевое определение, которое все цитируют как «важные вещи», на самом деле принадлежит не ему, а Ральфу Джонсону (одному из «банды четырёх», авторов книги о паттернах) — оно родилось в их переписке. Стоит атрибутировать честно, потому что путь к этому определению важнее самой фразы.
Джонсон последовательно разбил два привычных понимания:
🔨 «Архитектура — это фундаментальная организация системы / то, как связаны компоненты верхнего уровня». Возражение: нет объективного способа решить, что именно «фундаментально» и «верхнеуровнево». Лучшая формулировка, по Джонсону, — это общее понимание устройства системы, которое разделяют опытные разработчики. То есть архитектура — это не диаграмма на стене, а согласованная ментальная модель в головах команды.
🔨 «Архитектура — это решения, которые надо принять в начале проекта». Возражение тоньше и, по-моему, гениальное: это скорее решения, которые ты хотел бы успеть принять правильно в начале. Почувствуйте разницу — речь о решениях с высокой ценой разворота, а не о тех, что просто хронологически идут первыми.
Отсюда итог Джонсона: «Архитектура — это про важные вещи. Какими бы они ни были». Звучит как банальность, но смысл плотный: суть архитектурного мышления — решить, что важно (то есть что вообще является архитектурой), и тратить силы на поддержание именно этих элементов в порядке. А чтобы разработчик вырос в архитектора, ему надо научиться распознавать, какие элементы критичны и какие создадут серьёзные проблемы, если их не контролировать.
И здесь же — личная позиция Фаулера, объясняющая, почему он вообще не любит слово «архитектура»: оно отдаёт отрывом от программирования и нездоровой помпезностью. Его лекарство от этого: хорошая архитектура поддерживает собственную эволюцию и неразрывно сплетена с программированием. Не башня из слоновой кости, не отдельная каста архитекторов, рисующих квадратики, — а свойство живого кода. Telegraph не зря назвал это «архитектура — не чертежи, а разговор»: это честная передача мысли.
📉 Почему это окупается: экономика «крафта»
Дальше Фаулер делает то, что мало кто умеет, — переводит абстрактную «чистоту кода» в деньги и сроки. Главный злодей здесь — cruft (круфт): элементы софта, которые мешают разработчикам понимать систему. Чем больше круфта, тем медленнее и дефектнее выходят новые фичи.
И тут контринтуитивный поворот, ради которого стоит читать. Мы привыкли, что «высокое качество» = «дороже». Для пользовательского качества (UX, фичи) это часто так. Но для внутреннего качества (архитектура, чистота кода) зависимость переворачивается:
📈 Высокое внутреннее качество ведёт к более быстрой поставке фич — просто потому, что круфт не стоит на пути. Качество здесь не противоположность скорости, а её источник.
Вот тут — обязательное уточнение в духе «точность над драмой», которое бриф смазал. Фаулер пишет, что «опытные разработчики оценивают, что внимание к внутреннему качеству окупается за недели, а не месяцы». Но он тут же честно оговаривает: это нельзя объективно измерить. Это не данные, а инженерное суждение. Так что когда новость подаёт это как «разработчики подтверждают», она чуть-чуть подменяет «прикидывают на опыте» на «доказали». Разница принципиальная для того, кто ценит интеллектуальную честность.
Но вот что я бы добавил от себя, и это усиливает тезис Фаулера сильнее, чем его собственная осторожная оговорка 2019 года: с тех пор появилось исследование DORA и книга «Accelerate» (Форсгрен, Хамбл, Ким). Они на больших выборках показали, что скорость и стабильность поставки — не размен: высокоэффективные команды получают и то, и другое одновременно, и один из ключевых факторов — слабо связанная архитектура. То есть «недели, а не месяцы» так и осталось прикидкой, но более широкий тезис («внутреннее качество ускоряет, а не тормозит») за прошедшие годы получил эмпирический хребет. Фаулер был прав, просто тогда у него не было цифр.
⚙️ Из чего собран гид: карта, а не учебник
Важно понимать жанр: это не монолитный трактат, а кураторский хаб — Фаулер собрал и свои тексты, и работы коллег по Thoughtworks, разложив их по масштабу решений. Поэтому, кстати, «концентрат его многолетних размышлений» — не совсем точно: многое здесь написано другими (Майк Робертс, Кэм Джексон, Унмеш Джоши, Грегор Хоупе и др.), Фаулер выступает скорее как составитель и редактор.
Структура построена вокруг простой идеи: важность решений зависит от масштаба контекста. Отсюда два больших раздела — архитектура приложения и архитектура предприятия.
На уровне приложения собрано то, с чем builder сталкивается каждый день:
🔧 Микросервисы (Фаулер и Джеймс Льюис) — и тут гид честен про цену: рост распределённости, ослабленная согласованность данных и требование операционной зрелости. Это противоядие от карго-культа: микросервисы модны, но Фаулер прямо пишет, что они идут с издержками, и не каждому проекту нужны. Для тех, кто строит распределённые системы, это отрезвляющее напоминание считать не только плюсы.
🔧 Serverless (Майк Робертс) — про BaaS и FaaS, эфемерные контейнеры, уход от «всегда включённого» сервера: дешевле в эксплуатации, но ценой привязки к вендору и незрелости поддержки.
🔧 GUI-архитектуры (Фаулер, 2006) — увлекательная археология MVC и того, как из него выросли MVP, Presentation Model, MVVM. Главный тезис: MVC — один из самых неправильно понятых паттернов, а его суть — разделение представления и доменной логики плюс синхронизация состояния через события (паттерн «наблюдатель»). Полезно тем, кто думает, что «знает MVC».
🔧 Каталог паттернов распределённых систем (Унмеш Джоши) — про репликацию, рассинхронизацию, ненадёжные узлы и сетевые задержки. Прямая практика для всех, кто держит несколько копий данных.
🔧 Плюс приятные мелочи вроде feature toggles, микрофронтендов и слоения «представление — домен — данные».
Отдельно отмечу концепцию, которую недооценивают: приложение — это социальный конструкт. У Фаулера три определения границы приложения сразу: код, который разработчики видят как единое целое; функциональность, которую бизнес видит как единое целое; инициатива, которую держатели бюджета видят как одну статью расходов. Это растворяет кучу бессмысленных споров — «где кончается один микросервис и начинается другой», «это часть ОС или приложения». Границы софта объективно не существуют, они проводятся социально. Очень полезная оптика.
🏢 Enterprise: между скалами хаоса и удушающего контроля
На уровне предприятия — другая задача: координация между множеством команд с разными кодовыми базами, бюджетами и пользователями. И весь вопрос, по Фаулеру, в том, что стоит цены центральной координации, а что нет.
Он рисует пролив с двумя скалами:
🪨 На одном берегу — центральная архитектурная группа, которая утверждает каждое решение в каждой системе. Итог: замедление, и при этом группа физически не может понимать все нюансы огромного портфеля — отсюда плохие решения.
🪨 На другом — полное отсутствие координации: дублирование усилий, системы не стыкуются друг с другом, команды не учатся друг у друга.
Сам Фаулер с его agile-уклоном честно признаётся, что предпочитает держаться ближе к скале хаоса, чем к удушающему контролю, — но подчёркивает, что и об эту скалу тоже можно разбиться. Цель — максимум локальных решений при минимуме реальных издержек. Это и есть «ловушки», о которых говорит бриф, и здесь он передаёт мысль точно.
💬 Моё мнение
Самая нагруженная, несущая идея гида — это переопределение архитектуры через цену разворота решения и общее понимание команды. Потому что она отвечает на главный практический вопрос: куда тратить ограниченное внимание? Не всё является архитектурой. Архитектурно то, что дорого менять и что сломает вам жизнь, если выйдет из-под контроля. Это сразу отсекает и оверинжиниринг (заранее «правильно» спроектировать то, что дёшево поменять потом, — пустая трата), и недосмотр (оставить без присмотра то, что потом не развернёшь).
Но честно и про слабое место, раз уж мы за точность. Среди практиков есть резонная критика (её хорошо сформулировали инженеры, строившие распределённые системы в больших компаниях): то, что Фаулер называет «гидом по архитектуре», по факту — каталог паттернов и подходов. А реальная работа архитектора — это не «подобрать подходящий паттерн», а разобрать бизнес-кейс, ограничения, продумать размены на коротком-среднем-длинном горизонте, набросать на доске, поспорить, собрать MVP, снять выводы. Гид силён в философии («что такое хорошая архитектура») и как справочник паттернов — но он почти не про сам процесс принятия архитектурных решений под давлением бизнеса. Это не порок, а граница жанра, но знать о ней стоит, чтобы не принять карту за территорию.
И ещё одно. То, что гид не обновляли по-крупному с 2019-го, — это не баг, а фича. Технологии в нём (микросервисы, serverless) можно было бы освежить, но фундамент — определение через важность, экономика круфта, разделение масштабов, дилемма централизации — не сдвинулся ни на сантиметр. Хорошая абстракция тем и хороша, что переживает свои примеры.
🔮 Что дальше: архитектурное мышление в эпоху, когда код пишет ИИ
И вот тут — почему перечитать это именно сейчас. Аргумент Фаулера про круфт построен на молчаливой посылке: писать код дорого, поэтому накопленный беспорядок дорого обходится. Но теперь генерация кода стала почти бесплатной. И это не отменяет тезис, а усиливает его до предела.
Когда код штампуется ассистентом тоннами, круфт копится быстрее, чем человек успевает его осмыслить, — а «общее понимание системы опытными разработчиками», то самое джонсоновское определение архитектуры, оказывается под ударом: понимать-то нужно код, который ты не писал. Узкое место смещается ровно туда, куда показывал Фаулер: не в скорость написания, а во внутреннее качество и в способность команды удерживать связную ментальную модель. Дёшево сгенерировать — не то же самое, что дёшево сопровождать.
Так что я бы прочитал этот гид не как музейный экспонат 2019 года, а как инструкцию, ставшую актуальнее с появлением LLM-кодогенерации. Решать, что важно, и беречь именно это — навык, который машине пока не делегируешь. И чем дешевле становится сам код, тем дороже стоит человек, умеющий отличить архитектурно значимое от шума.
Источники:
- 🔗 Software Architecture Guide (оригинал): martinfowler.com/architecture
- 📖 Разбор на Telegraph: telegra.ph/Arhitektura--ehto-ne-chertezhi-a-razgovor…
- 📄 «Who Needs an Architect?» — колонка Фаулера в IEEE Software, откуда растёт определение Джонсона: martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
- 📄 «Is High Quality Software Worth the Cost?» — статья про круфт и «недели, а не месяцы»: martinfowler.com/articles/is-quality-worth-cost.html
- 🔧 Microservices Guide (Фаулер и Джеймс Льюис): martinfowler.com/microservices
- 🔧 Serverless Architectures (Майк Робертс): martinfowler.com/articles/serverless.html