Карта курса: 31 понятие в восьми группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Архитектура — это не набор технологий, а набор вопросов, которые надо задать до того, как писать код. Каждый вопрос в индустрии имеет своё английское имя: Trade-offs, Coupling, Idempotency, ADR. Курс собирает их в восемь групп — по ним идут главы 1–8.

Как читать курс

Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

У каждого понятия одно и то же: английское название (запомни его — это термин, по которому ищут и о котором спрашивают на собеседованиях), образ из жизни, схема и карточка с полями: что это, зачем, пример, ловушка (где обычно ошибаются) и связи с другими понятиями. В конце главы — главный вопрос, в конце курса — чек-листы и шпаргалка.

Problem Framing — сомневаться в задаче, а не только в решении

К врачу пришли с просьбой выписать рецепт. Хороший врач сначала спросит, что болит, и может выяснить, что лекарство было бы неправильным.

Когда тебе говорят «сделай X», инженер спрашивает «как сделать X». Архитектор спрашивает «зачем нужен X, и не решит ли проблему что-то другое». Это и есть problem framing — постановка проблемы. Часто оказывается, что задача поставлена неверно — и решение, которое тебе заказали, через год превратится в проблему.

Long-term Thinking — горизонт в годы и ответственность за последствия

Инженер строит дом для семьи, которая въезжает в субботу. Архитектор спрашивает: «А когда у них родится третий ребёнок? А когда мать переедет к ним? А если они захотят сдавать первый этаж?»

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

Если плотник криво забил гвоздь — переделают за день. Если архитектор поставил несущую стену не там — дом не перестроить, в нём придётся жить.

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

Trade-offs — каждое решение что-то выигрывает и что-то проигрывает

Велосипед быстрее пешехода, но мокнет под дождём. Машина не мокнет, но застревает в пробке. Метро не застревает, но не везёт до двери.

Когда инженер выбирает технологию, он часто ищет «лучшую». Это иллюзия. Архитектор знает: любой выбор — это компромисс (trade-off) по нескольким осям: скорость разработки против поддерживаемости, простота против гибкости, стоимость сейчас против стоимости через три года. Назвать оси и осознанно выбрать — главная архитектурная работа.

Simplicity (KISS) — простое решение почти всегда правильнее сложного

Швейцарский нож умеет всё, но плохо. Один хороший нож режет лучше всех своих собратьев в швейцарском.

Инженер боится упустить требование и закладывает в систему всё, что только может понадобиться. Архитектор знает: каждая возможность, которой никто не пользуется, — это вечный налог на разработку. Сложность нужно вводить осознанно, когда она оправдана; по умолчанию — простое решение, которое легко поменять. Этот принцип часто называют KISS — Keep It Simple, Stupid.

Reversibility — решения, которые сложно отменить, требуют больше внимания

В ресторане можно вернуть заказ. На свадьбе нельзя вернуть «да».

Не все архитектурные решения равны по цене ошибки. Выбор языка программирования или базы данных — почти необратим. Выбор библиотеки для логирования — обратим за день. Архитектор тратит непропорционально много времени на необратимые решения и быстро принимает обратимые. В индустрии это часто называют one-way door (дверь в одну сторону) и two-way door (дверь, через которую можно вернуться).

Technical Debt — сознательный выбор, а не лень

Кредит на бизнес — это нормально, если ты знаешь, когда и из чего будешь его отдавать. Кредит без плана возврата — путь к банкротству.

Иногда правильно сейчас сделать решение, которое потом придётся переписать. Это и есть технический долг (technical debt). Это нормально. Ненормально — не отдавать себе отчёт, что это долг. Архитектор записывает, какие компромиссы были приняты, почему, и когда их нужно пересмотреть.

Decomposition — главный навык архитектора

Невозможно съесть кита целиком. Можно — если разрезать на куски, которые помещаются в рот.

Большая система непостижима. Декомпозиция (decomposition) — умение разрезать её на части. Хорошая архитектура — это набор маленьких частей, каждую из которых можно понять в одиночку. Если для объяснения одного компонента приходится рассказывать про три других — декомпозиция плохая.

Cohesion & Coupling — высокая связность внутри, низкая зацепленность снаружи

Хорошая квартира: кухня внутри объединена логично (плита рядом с раковиной), а с соседями — общая только одна стена.

Внутри одного модуля всё должно быть про одну тему — это высокая связность (high cohesion). Между модулями — минимум контактов, через ясный интерфейс — это низкая зацепленность (low coupling). Если поменял что-то в одном модуле и пришлось трогать пять других — зацепленность между ними слишком высокая.

Layers & the Dependency Rule — слои про направление зависимостей

Этажи дома: третий этаж стоит на втором, второй на первом, первый на фундаменте. Нельзя ставить фундамент на третий этаж.

В хорошей архитектуре бизнес-логика не знает про базу данных, веб-интерфейс или фреймворк. Внутренние слои не зависят от внешних — это правило зависимостей (dependency rule). Когда нужно сменить базу данных или фреймворк, бизнес-логика остаётся нетронутой. Это Clean Architecture в одной фразе.

Interface over Implementation — интерфейс важнее реализации

Тебе всё равно, какой марки лифт в здании. Важно, чтобы кнопки работали одинаково, двери открывались надёжно, и звук был тихий.

Когда модуль взаимодействует с другим, важен контракт между ними (interface), а не то, как другой устроен изнутри (implementation). Сначала проектируется граница (API, интерфейс класса, схема сообщения), потом — реализация. Меняй реализацию свободно, контракт — только с осознанием последствий.

Monolith vs Microservices — вопрос не моды, а зрелости

Один повар на маленькой кухне делает блюдо быстрее, чем десять поваров с переговорами в Slack. Сто блюд в час десять поваров делают лучше.

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

Data Model — модель данных переживает всё остальное

Фундамент дома стоит дольше всех стен и крыш, которые на нём построят за столетие.

Языки уйдут, фреймворки сменятся, дизайн интерфейса перерисуют десять раз. Структура данных (data model), заложенная в начале, будет жить — потому что менять её на работающей системе очень дорого. Это первое, на что архитектор тратит время, и последнее, что он спешит зафиксировать.

Single Source of Truth — каждый факт хранится в одном месте

Если в семье у каждого свой список покупок — двое купят молоко, никто не купит хлеб.

Одна и та же информация в двух местах — гарантированный путь к рассинхрону. Принцип единого источника правды (single source of truth, SSOT): архитектор определяет, где живёт каждый факт системы. Если данные дублируются (для скорости, например), нужно явно определить, что — источник правды, а что — кэш или проекция.

State — сложность; чем меньше, тем лучше

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

Каждый кусок состояния (state), который где-то хранится, — это что-то, что может рассинхронизироваться, потеряться, противоречить другому состоянию. Хорошая архитектура стремится к функциям без памяти (stateless) и переменным с коротким временем жизни. Состояние оставляется там, где оно действительно необходимо — обычно в базе данных.

Transactions — атомарность намерения

Перевод денег — это два действия, но одно намерение. Либо обе записи произошли, либо ни одной. Половина — катастрофа.

Когда несколько изменений должны произойти как единое целое, нужны транзакции (transactions). Это свойство называют атомарностью (atomicity). Архитектор знает, какие операции в системе атомарны, какие могут провалиться частично, и как с этим жить. В распределённых системах это становится центральной проблемой (двухфазный коммит, сага, идемпотентность).

Cache — вторая правда, и она может лгать

Календарь на холодильнике быстрее, чем заглянуть в телефон. Но если кто-то изменил расписание в телефоне — холодильник уже врёт.

Кеш (cache) даёт скорость, но забирает гарантию свежести. Архитектор всегда понимает: что у нас закешировано, как долго, и что произойдёт, если кеш врёт. Самый сложный вопрос в кешировании — не как добавить кеш, а как его инвалидировать (cache invalidation).

API Contract — граница системы это контракт, а не код

Граница между странами — это не забор, а правила: что можно перевозить, кому въезжать, какой паспорт нужен.

API, схема сообщения, формат файла — это обещание перед всеми, кто этим пользуется. Менять контракт — это менять обещание, и стоит это дорого. Хороший архитектор проектирует контракты так, чтобы их можно было расширять без поломки старых клиентов (добавлять поля, не убирать). Это свойство называют обратной совместимостью (backward compatibility).

Sync vs Async — выбор связанности во времени

Телефонный звонок: оба должны быть онлайн одновременно. Письмо: получатель прочтёт, когда удобно.

Синхронный вызов (synchronous) связывает два сервиса во времени: если получатель сломан, отправитель тоже встал. Асинхронная связь (asynchronous) через очередь сообщений разрывает эту связь: отправитель кладёт письмо и идёт дальше. Это даёт устойчивость, но добавляет сложность: задержки, дубликаты, порядок.

Idempotency — операцию можно повторить безопасно

Лифт нажат на третий этаж. Если десять человек нажмут ту же кнопку ещё раз — лифт всё равно едет на третий, ничего не ломается.

В реальных системах вызовы повторяются: из-за таймаутов, сетевых сбоев, перезапусков. Идемпотентная (idempotent) операция при повторе даёт тот же результат. Операция, которую опасно повторять, — это бомба замедленного действия. Архитектор делает критичные операции (платежи, обработка сообщений) идемпотентными по умолчанию.

External Dependencies — внешние зависимости это всегда риск

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

Каждая внешняя система (external dependency) — API, сервис, библиотека — может стать недоступной, медленной или поменять контракт. Архитектор определяет, что произойдёт, когда это случится: вся система упадёт, или продолжит работать с деградацией. Часто стоит изолировать внешнюю зависимость через свой слой (adapter) — чтобы потом её можно было заменить.

Security — не функция, а образ жизни системы

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

Безопасность (security) нельзя добавить в конце. Она встраивается на каждом уровне: аутентификация, авторизация, шифрование, изоляция, аудит, минимальные привилегии (least privilege). Такой подход слоями называют defense in depth — защита в глубину. Архитектор думает о ней с первого дня и спрашивает на каждом решении: «А что, если злоумышленник получит сюда доступ?»

Такси на трёх человек не должно везти как скоростной поезд. Скоростной поезд не подойдёт, чтобы заехать в переулок.

«Сделай быстро» — бессмысленное требование. Архитектор формулирует производительность (performance) в числах: сколько запросов в секунду (throughput), какая задержка (latency) терпима, как ведёт себя система под пиком, что происходит при превышении. Оптимизировать раньше времени — потеря; не подумать вообще — катастрофа.

Scalability — умение расти, не переписываясь

Дом, в котором заложена возможность пристроить второй этаж, расширяется без сноса. Дом без такой возможности — только перестройкой с нуля.

Масштабируемость (scalability) — система должна расти в две стороны: больше пользователей (горизонтально — добавили серверов) и больше функций (модульно — добавили модулей, не сломав старые). Это закладывается в дизайне, а не приделывается потом.

Reliability — поведение системы, когда что-то сломалось

Хороший корабль не тот, который не тонет (таких не бывает), а тот, у которого десять отсеков, и при пробое одного — остальные продолжают плыть.

Любая часть системы рано или поздно сломается. Надёжность (reliability) — не «никогда не ломается», а «переживает сбой». Архитектор не пытается предотвратить поломку — он проектирует, как система переживёт сбой: изоляция отказов, повторные попытки (retries), грациозная деградация (graceful degradation), фолбэки (fallback). Главное правило: сбой одного компонента не должен убить всю систему.

Observability — нельзя чинить то, чего не видишь

Машина без датчиков топлива, температуры и давления масла. Едет, пока не сломается насмерть.

Наблюдаемость (observability) — система должна сама рассказывать о своём состоянии: логи (logs), метрики (metrics), трассировки (traces). Когда что-то идёт не так в три ночи, у тебя есть минуты, чтобы найти проблему. Если наблюдаемость не заложена с начала — её добавлять поздно: непонятно даже, где смотреть.

Evolvability — готовность к изменениям важнее правильности сегодня

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

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

Переезд из старого дома в новый — это процесс на месяцы. Нельзя просто выкинуть всё и купить заново.

Когда систему нужно изменить (новая база, новый протокол, новая модель данных) — это не «переписать с нуля», а «провести через переходный период». Это и есть миграция (migration). Реальные системы работают во время изменений. Архитектор думает о пути миграции с самого начала, иначе переход становится невозможным.

YAGNI & Deletion — удалять важнее, чем добавлять

Шкаф нельзя расширять бесконечно. Иногда нужно выбросить старое, чтобы поместилось новое.

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

Самая прочная стена — та, которую не пришлось ломать, потому что под неё ничего не подкладывали лишнего.

Иногда правильное архитектурное решение — не делать архитектурного решения. Не вводить уровень абстракции «на будущее». Не разделять монолит «потому что когда-нибудь». Не строить плагинную систему «потому что мало ли». Этот принцип называют YAGNI — You Aren't Gonna Need It, «тебе это не понадобится». Хороший архитектор знает, когда сказать «не сейчас» или «нам это не нужно».

ADR — архитектурное решение записывается, иначе оно потеряется

Устное завещание исчезает с автором. Записанное — переживает поколения.

Каждое значимое архитектурное решение нужно зафиксировать: что выбрали, какие были альтернативы, почему отказались от них, какие компромиссы приняли. Этот документ нужен не сейчас — а через год, когда придёт новый человек и спросит «а почему так странно сделано?». Стандартный формат — ADR (Architecture Decision Record).

C4 Model — диаграмма стоит тысячи слов

Описать словами, как добраться до дома, — долго и часто бесполезно. Показать карту — секунда.

У архитектора всегда есть диаграмма системы: какие компоненты, как они связаны, где границы. Не идеальная — рабочая. Она нужна, чтобы быстро объяснить новому человеку и чтобы самому видеть систему целиком. Модель C4 (Context, Container, Component, Code) — простая и достаточная для большинства случаев.

Хороший врач объясняет диагноз пациенту словами, которые тот понимает. Плохой — медицинскими терминами, после которых пациент кивает и ничего не понимает.

Если архитектор может объяснить решение только другим инженерам — он пропустил половину работы. Бизнес-стороны, продукт, юристы, безопасность — все заинтересованные стороны (stakeholders) должны понимать последствия. Умение перевести техническое решение в бизнес-язык (стоимость, риск, время) — одно из главных умений архитектора.

Хирург, который соглашается на любую просьбу, теряет пациентов. Хороший — отказывает, когда операция убьёт.

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

Как понятия связаны между собой

Ящик с инструментами: молоток не работает без гвоздей, а гвозди — без молотка.

Понятия курса не живут поодиночке. Решение начинается с Problem Framing, взвешивается как Trade-off, проверяется на Reversibility и записывается в ADR. Систему режут Decomposition, качество разреза меряют Cohesion & Coupling, части встречаются на Interface. Копии данных живут при Single Source of Truth, а повторы в асинхронном мире требуют Idempotency.