Course map — 24 модуля в шести частях

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

Курс идёт от мышления к практике. Сначала — как думает архитектор (mindset). Потом — как устроена система внутри (structure) и что меняется, когда она расползается по сети (distribution). Дальше — свойства качества (quality attributes), работа с людьми (people) и то, куда профессия движется (future).

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

Long-term thinking — архитектор думает горизонтом лет

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

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

Главный сдвиг в голове: ты перестаёшь спрашивать только «как сделать X» и начинаешь спрашивать «зачем нужен X, какие есть альтернативы, что мы потеряем и как это решение будет выглядеть через три года».

Reversible vs irreversible decisions — отвечать за форму системы

Если плотник ошибся с полкой, её можно перевесить. Если проектировщик ошибся с несущей стеной, дом будет жить с этой ошибкой десятилетиями.

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

Здесь полезно различать reversible decisions и irreversible decisions. Обратимое решение можно поменять за день или неделю: библиотека логирования, цвет кнопки, мелкая внутренняя структура модуля. Необратимое или дорого обратимое решение меняет траекторию системы: база данных, модель tenancy, API-контракт, способ хранения событий, границы сервисов.

Trade-off — best practice без контекста — плохой совет

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

Архитектурное решение нельзя оценивать вне контекста. REST, GraphQL, Kafka, PostgreSQL, Kubernetes, микросервисы, монолит — всё это инструменты с ценой. Trade-off — это осознанный обмен: latency против throughput, consistency против availability, time-to-market против maintainability, простота против гибкости.

Архитектор не говорит «Kafka лучше RabbitMQ». Он говорит: «нам нужен порядок событий по ключу, высокий throughput, replay и долговечный log; за это мы платим операционной сложностью Kafka». Так звучит профессиональный язык.

Over-engineering vs under-engineering — сложность как налог

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

Сложность бывает полезной, когда она покупает важное свойство: изоляцию отказов, независимый релиз, безопасность, масштабирование, тестируемость. Но сложность «на будущее» чаще всего становится постоянным налогом.

Термины over-engineering и under-engineering полезны только вместе. Over-engineering — когда сложность появилась раньше реальной боли. Under-engineering — когда система уже упёрлась в ограничения, а архитектура не оставила пути роста. Работа архитектора — не выбрать крайность, а удерживать середину.

Technical debt — кредит, а не мусор

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

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

Полезная модель — квадрант Мартина Фаулера (Technical Debt Quadrant): deliberate / inadvertent и prudent / reckless. Осознанный разумный долг: «мы временно не делаем multi-region, потому что у нас 200 пользователей и один рынок». Неосознанный безрассудный долг: «мы не знали, что транзакции нужны».

Debt interest — у долга есть проценты

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

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

Архитектор договаривается о стратегии выплаты: что именно считаем долгом, какой риск он создаёт, когда пересматриваем решение, какой сигнал говорит «пора платить». Без этого «технический долг» становится эмоциональным аргументом, а не управляемым инструментом.

Cognitive load — архитектура должна помещаться в голову

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

Cognitive load — это умственная нагрузка, которую система требует от инженера. Есть intrinsic load: сложность самой предметной области. Есть extraneous load: лишняя сложность от плохой архитектуры, неочевидных связей, случайных исключений и магии. Архитектор не может убрать сложность бизнеса, но обязан снижать лишнюю сложность.

Хороший модуль можно понять отдельно. Хороший bounded context имеет свой язык и свои инварианты. Хорошая команда владеет областью, которая помещается в её голову.

Conway's Law — структура команд становится структурой системы

Если три отдела не разговаривают друг с другом, их продукт почти всегда выглядит как три продукта, склеенные в одном меню.

Conway's Law говорит: организация проектирует системы, похожие на структуру коммуникации внутри организации. Если архитектурные границы не совпадают с командными границами, команда будет постоянно пересекать чужую территорию.

Team Topologies вводит полезные термины: stream-aligned team, platform team, enabling team, complicated-subsystem team. Это не HR-мода, а архитектурный инструмент: иногда правильная декомпозиция системы начинается с правильной декомпозиции ответственности.

Cohesion & coupling — резать по слоям, по доменам и по потоку данных

Мясник режет тушу не как попало, а по суставам. Хорошая декомпозиция тоже ищет естественные места разрыва.

Декомпозиция — это не «разложить по папкам». Это выбор границ ответственности. High cohesion означает, что внутри компонента всё связано одной темой. Low coupling означает, что компонент мало знает о других компонентах.

Горизонтальный разрез даёт слои (layers): UI, application, domain, infrastructure. Вертикальный разрез даёт фичи или bounded contexts: billing, identity, catalog, comments. В реальных системах нужны оба, но опасно путать одно с другим.

Bounded context — плохая граница выдаёт себя изменениями

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

Признак плохой декомпозиции: маленькое изменение расползается по пяти модулям. Ещё один признак: один модуль меняется по разным причинам — сегодня из-за продукта, завтра из-за базы, послезавтра из-за интеграции.

DDD-термин bounded context полезен именно здесь. Это граница, внутри которой слова имеют один смысл. Например, «Customer» в billing и «Customer» в support могут быть разными моделями. Насильственное объединение таких понятий часто создаёт хрупкую «универсальную» модель.

Dependency Rule и DIP — зависимости текут к центру

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

Clean Architecture, Hexagonal Architecture и Onion Architecture говорят об одном: важная логика должна быть в центре, детали — снаружи. HTTP, SQLAlchemy, Next.js, Kafka, Redis, Stripe — это детали. Они важны, но они не должны определять бизнес-правила.

Dependency Inversion Principle означает: высокоуровневая логика зависит от абстракций, а реализации подключаются снаружи. В коде это выглядит как ports and adapters: service получает PaymentGatewayProtocol, а не создаёт StripeClient внутри себя.

Abstraction — нужна под давлением изменений, а не для красоты

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

Не каждый класс требует интерфейса. Но всё, что связано с внешним миром, временем, случайностью, сетью, файловой системой и базой данных, должно быть заменяемо в тестах. Иначе ты не тестируешь бизнес-логику, а запускаешь маленькую production-систему в unit-тесте.

Цена слоя — больше файлов и больше слов. Выигрыш — тестируемость, сменяемость инфраструктуры, ясные границы. Если выигрыша нет, слой лишний.

API contract — контракт важнее транспорта

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

REST, GraphQL, gRPC и WebSocket — разные способы общения. REST хорош для resource-oriented API и простого кэширования. GraphQL полезен, когда клиентам нужны разные формы чтения. gRPC хорош для typed service-to-service коммуникации. WebSocket нужен для двусторонних событий в реальном времени.

Выбор транспорта вторичен. Главное — контракт (API contract): схема, ошибки, идемпотентность, версионирование, backward compatibility, deprecation policy.

Idempotency — спасение от реального мира

Если ты нажал кнопку лифта десять раз, лифт не должен десять раз приехать и уехать. Он должен понять, что намерение одно.

Idempotency означает, что повтор операции даёт тот же итоговый эффект. В сетевых системах повторы неизбежны: timeout, retry, дубль webhook, перезапуск worker-а. Если создание платежа, заказа или сообщения не идемпотентно, система рано или поздно сделает лишнее.

Архитектор проектирует идемпотентность на уровне контракта: idempotency key, уникальные constraints, безопасные retry, понятные статусы.

Data model — данные живут дольше приложений

Фасад здания можно перекрасить за неделю. Фундамент, залитый неправильно, будет напоминать о себе весь срок жизни здания.

Язык, фреймворк и UI могут смениться несколько раз. Но таблицы, события, ключи, связи и исторические записи остаются. Ошибка в модели данных часто становится ошибкой всех будущих версий продукта.

Нормализация (normalization) снижает дублирование и риск рассинхрона. Денормализация (denormalization) ускоряет чтение и упрощает read model. OLTP системы оптимизированы под транзакции, OLAP — под аналитику. Нельзя проектировать одну модель так, будто она идеально решит оба класса задач.

Event sourcing и CQRS — сильный инструмент, не религия

Банковская выписка хранит не только текущий баланс, а историю операций. Это позволяет объяснить, откуда баланс взялся.

Event sourcing хранит изменения как последовательность событий, а текущее состояние строит из них. Это полезно, когда важна история, аудит, восстановление состояния, replay. Но цена высокая: schema evolution событий, сложность запросов, eventual consistency, требования к tooling.

CQRS разделяет write model и read model. Это может сильно упростить сложные системы чтения, но добавляет синхронизацию и задержки. Вводить CQRS только потому что «так архитектурно» — дорогой способ получить две проблемы вместо одной.

Single source of truth — не значит single database

В компании может быть много отчётов, но должен быть один официальный реестр зарплат. Иначе в день выплат начнётся театр.

Single source of truth означает, что для каждого важного факта понятно, где живёт авторитетная версия. Кэш, поисковый индекс, read replica, materialized view — это производные копии. Они могут быть полезны, но не должны притворяться первичной правдой.

Stateful компоненты хранят состояние и требуют аккуратности: транзакции, locking, recovery, backup. Stateless компоненты проще масштабировать и заменять, но они всё равно зависят от состояния где-то ещё.

Cache и locking — вторая правда, которая иногда врёт

Расписание на холодильнике удобно, пока кто-то не перенёс встречу в календаре телефона.

Кэш (cache) покупает скорость ценой свежести. Самый сложный вопрос кэша — не «как положить», а «когда инвалидировать». TTL, explicit invalidation, write-through, write-behind, cache-aside — это разные компромиссы между сложностью, свежестью и нагрузкой.

Race condition появляется, когда две операции конкурируют за состояние. Optimistic locking говорит: «конфликты редки, проверим версию при записи». Pessimistic locking говорит: «конфликты опасны, заблокируем заранее». Оба подхода правильны в разных условиях.

CAP и PACELC — сеть как источник неопределённости

Монолит — разговор в одной комнате. Распределённая система — переписка между людьми в разных часовых поясах, где письма иногда теряются, приходят дважды или задерживаются.

В распределённой системе нельзя просто «вызвать функцию». Между сервисами есть сеть, timeout, retry, partial failure, разные часы, разные версии кода. То, что в монолите было локальной транзакцией, становится протоколом координации.

CAP theorem часто пересказывают плохо. Практически полезнее помнить: при network partition ты выбираешь между consistency и availability. PACELC добавляет: даже когда partition нет, ты всё равно выбираешь между latency и consistency.

Consistency models и Saga — согласованность бывает разной

Если два человека смотрят один документ в Google Docs, они почти сразу видят одно и то же. Если два человека смотрят банковский перевод, «почти» уже недостаточно.

Strong consistency даёт свежую правду, но стоит latency и availability. Eventual consistency допускает временный рассинхрон, но часто лучше масштабируется. Causal consistency сохраняет причинный порядок: если событие B зависит от A, B не должно быть видно раньше A.

Saga pattern помогает разложить длинную бизнес-транзакцию на шаги с compensating actions. Two-phase commit даёт атомарность между ресурсами, но дорог и хрупок в реальных распределённых системах. Архитектор выбирает не «самую строгую» модель, а достаточную для риска.

Modular monolith — часто недооценённый старт

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

Монолит — не оскорбление. Плохой монолит — это ком грязных зависимостей. Хороший modular monolith имеет строгие внутренние границы, отдельные домены, явные интерфейсы и одну deployment unit. Для маленькой команды это часто лучший старт.

Микросервисы (microservices) помогают, когда нужны независимые релизы, автономные команды, разные scaling profiles, изоляция отказов, разные технологические стеки. Но цена: network calls, observability, distributed transactions, DevOps overhead, versioning, security между сервисами.

Distributed monolith и Strangler Fig — худшее из двух миров и выход

Это как жить в разных квартирах, но ходить друг к другу за каждой ложкой.

Distributed monolith выглядит как микросервисы, но сервисы не автономны: общий database schema, синхронные цепочки вызовов, релизы только вместе, изменения требуют трогать всех. Команда платит стоимость распределённости, не получая независимости.

Strangler Fig pattern помогает мигрировать аккуратно: оборачиваем старую систему, постепенно выносим capabilities, режем по реальной бизнес-границе, а не по таблицам.

Queue и pub/sub — очередь это не просто «потом»

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

Синхронный запрос (sync) прост для понимания: отправил, получил ответ. Но если получатель медленный или недоступен, отправитель страдает. Асинхронность (async) через queue или pub/sub позволяет пережить сбои и пики нагрузки, но требует другой модели мышления.

Queue обычно распределяет работу между consumer-ами. Pub/sub рассылает событие многим подписчикам. Kafka, RabbitMQ, SQS, Redis Streams — разные инструменты с разной моделью ordering, durability, replay и operations.

At-least-once delivery — exactly-once почти всегда маркетинг

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

В реальности чаще проектируют at-least-once delivery плюс идемпотентный consumer. Сообщение может прийти дважды; обработчик должен пережить это. Dead letter queue нужна для сообщений, которые не получилось обработать после разумного числа попыток.

Backpressure — сигнал «получатель не успевает». Без него система красиво принимает всё, а потом умирает внутри.

Tail Latency — среднее время ответа почти всегда врёт

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

Это понятие tail latency — хвостовая задержка. Сначала три слова. Latency — задержка одной операции. Throughput — сколько операций система делает за единицу времени. Percentiles показывают распределение: p50 — медиана, p95 — 95% запросов быстрее этого значения, p99 — хвост.

Пользователь чувствует не среднее, а хвост. Tail latency особенно важна там, где один экран зависит от нескольких backend-вызовов: вероятность медленного ответа складывается.

Profiling — профилировать до оптимизации

Чинить производительность без профиля — как лечить пациента по фотографии обуви.

Это практика profiling: сначала измерить, потом оптимизировать. N+1 query, лишние round trips, плохой индекс, сериализация, lock contention, GC pause, холодный cache — все они выглядят как «медленно», но лечатся по-разному.

Amdahl's Law напоминает: ускорение ограничено частью системы, которую ты реально оптимизируешь. Little's Law помогает думать об очередях: больше latency при том же throughput означает больше work-in-progress внутри системы.

Vertical vs Horizontal Scaling — покупают разное

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

Vertical scaling (scale up) — усилить одну машину. Просто, пока хватает потолка. Horizontal scaling (scale out) — добавить больше экземпляров. Гибче, но требует stateless application layer, load balancing, shared state strategy и наблюдаемости.

Базы масштабируются сложнее приложений. Read replicas помогают чтению, но не записи. Sharding делит данные, но заставляет выбрать shard key. Плохой shard key превращает масштабирование в перекос нагрузки.

Scale Cube — масштабирование функций не менее важно

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

Система должна выдерживать не только больше traffic, но и больше product surface. Если каждая новая фича требует переписать общий God-service, система не масштабируется организационно.

Полезная модель здесь — scaling cube: X-axis — клонирование, Y-axis — разделение по функциям, Z-axis — partitioning по данным или tenants.

Retry, Circuit Breaker, Bulkhead — retry без стратегии создаёт атаку на самого себя

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

Retry нужен для transient failures. Но retry должен иметь лимит, timeout, exponential backoff и jitter. Иначе частичный сбой превращается в retry storm.

Circuit breaker временно прекращает вызовы к зависшему dependency. Bulkhead pattern изолирует ресурсы: если один downstream умирает, он не забирает все worker threads и connection pools.

SLI / SLO / SLA — SLO превращает надёжность в контракт

«Будем стараться» — не расписание поездов. Расписание говорит, что считается нормой, а что сбоем.

SLI — что измеряем: success rate, latency, freshness. SLO — целевой уровень: 99.9% успешных запросов за 30 дней. SLA — обещание клиенту с последствиями.

Error budget говорит, сколько ненадёжности мы можем потратить. Если бюджет сгорел, команда перестаёт гнаться за фичами и чинит надёжность. Это бизнесовый язык для инженерного качества.

Authentication vs Authorization — разные вещи

Паспорт подтверждает, кто ты. Билет подтверждает, куда тебе можно войти. Одно не заменяет другое.

Authentication (AuthN) отвечает на вопрос «кто это?». Authorization (AuthZ) — «что ему можно?». Путаница опасна: пользователь может быть корректно залогинен и всё равно не иметь права читать чужой invoice.

RBAC выдаёт права через роли. ABAC учитывает атрибуты: владельца ресурса, tenant, регион, состояние объекта. Session-based auth проще ревокировать, JWT проще проверять без базы, но сложнее отзывать. Выбор зависит от угроз и lifecycle.

Threat Modeling — это профессиональная паранойя

Хороший архитектор думает как злоумышленник не потому, что не доверяет людям, а потому что доверяет реальности.

Threat modeling — систематический поиск угроз до атаки. STRIDE помогает их искать: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Defense in depth означает несколько слоёв защиты: input validation, authz, encryption, audit log, rate limiting, least privilege.

Secrets management — не «положить ключ в env и забыть». Нужно понимать rotation, доступы, audit, blast radius и что произойдёт при утечке.

Observability — monitoring говорит, что плохо, observability помогает понять почему

Лампочка «check engine» полезна, но механику нужны ещё датчики, история и инструменты диагностики.

Monitoring отвечает «что-то не так». Observability — «почему». Три столпа observability: logs, metrics, traces. Structured logging делает логи queryable. Metrics показывают агрегаты. Distributed tracing связывает путь запроса через сервисы.

Correlation ID — маленькая вещь, которая спасает ночи: один request id проходит через gateway, service, queue, worker и downstream.

Symptom-based Alerting — алертить нужно на симптомы

Пользователю всё равно, что CPU 92%. Ему важно, что checkout не работает.

Хороший alert говорит о пользовательской боли — это symptom-based alerting: error rate, latency, failed payments, stale data. Плохой alert говорит о причине, которая может быть нормальной. Если алерты шумят, команда перестаёт им верить.

Runbook отвечает на вопрос «что делать в 03:00». Post-mortem отвечает «как мы сделаем, чтобы это не повторилось». Без обвинений (blameless); цель — улучшить систему, а не найти виновного.

ADR — Architecture Decision Record лучше памяти

Устная договорённость хороша до первого отпуска, увольнения или спора через полгода.

Architecture Decision Record фиксирует контекст, решение, альтернативы и последствия. ADR не должен быть романом. Хороший ADR отвечает: какую проблему решали, что выбрали, почему не выбрали другое, когда пересмотреть.

Документация нужна не для аудита, а для будущего изменения. Новый инженер должен понять не только «как», но и «почему».

C4 Model — диаграмма как рабочий инструмент, не украшение

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

C4 model даёт четыре уровня: Context, Container, Component, Code. Обычно хватает первых трёх. Sequence diagram полезна, когда важен порядок взаимодействия. UML целиком редко нужен; отдельные диаграммы — да.

Living documentation живёт рядом с кодом, обновляется в PR и проверяется ревью. Документ в заброшенной wiki быстро становится исторической фантастикой.

Risk Translation — переводить риск на язык аудитории

Врач не говорит пациенту только латинские названия. Он объясняет, что будет болеть, сколько лечить и что нельзя делать.

Это практика перевода риска. Инженеру можно сказать: «у нас нет idempotency на payment callback». Бизнесу нужно сказать: «при повторе webhook мы можем дважды списать или дважды выдать товар; это финансовый и репутационный риск».

Stakeholder mapping помогает понять, кому что важно: product хочет time-to-market, security — risk reduction, finance — predictable cost, support — понятное поведение, engineering — maintainability.

RFC — письменное предложение снижает температуру спора

Спор у доски часто выигрывает самый громкий. Письменное предложение заставляет аргументы стоять отдельно от голоса.

RFC (Request for Comments) описывает проблему, ограничения, варианты, выбранное решение, риски и план rollout. Хороший RFC приглашает к критике до того, как решение стало политикой.

Disagree and commit работает только после честного обсуждения. Если команда не была услышана, это не commit, а подавление.

Influence without Authority — влияние без формальной власти

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

Это понятие influence without authority. Архитектор не должен становиться bottleneck на каждое решение. Его задача — задать принципы, объяснить границы, вырастить людей и вмешиваться там, где цена ошибки высока.

Mentoring архитектора — это не «делай как я». Это обучение вопросам: какие альтернативы ты видел, что потерял, как протестируешь риск, где граница ответственности.

Delegation with Guardrails — делегировать не значит снять ответственность

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

Часть архитектурных решений должна приниматься командами. Иначе архитектор становится очередью. Но должны быть guardrails: принципы, review, ADR, platform constraints, quality gates.

Архитектор вмешивается, когда решение необратимо, ломает системные инварианты, создаёт security risk или влияет на несколько команд.

Non-functional Requirements — тоже бизнес-требования

Для магазина «checkout работает в Black Friday» — не техническая деталь, а деньги.

Non-functional requirements (NFR): performance, availability, security, compliance, operability — это не «технические хотелки». Это свойства продукта. Архитектор переводит их в business impact: потерянная выручка, риск штрафа, стоимость поддержки, скорость запуска рынков.

Cost of delay помогает обсуждать не только стоимость работы, но и стоимость ожидания. Иногда архитектурная инвестиция без немедленного ROI нужна, потому что без неё следующие фичи будут дорожать.

Build vs Buy — не вопрос гордости

Не каждая компания должна строить собственную электростанцию, чтобы включить свет.

Build даёт контроль и дифференциацию. Buy даёт скорость и снижает операционную нагрузку. Vendor lock-in — реальный риск, но сам по себе не аргумент против покупки. Вопрос: насколько дорого будет выйти, если поставщик изменит цену, API или качество?

Архитектор помогает продукту видеть capability map: какие способности являются ядром бизнеса, а какие лучше купить.

Specification-driven Development — spec quality становится bottleneck

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

AI-агенты ускоряют implementation, но не отменяют архитектуру. Плохо сформулированная задача просто быстрее превращается в плохой код. Specification-driven development означает, что основной артефакт — спецификация поведения, границ, инвариантов, тестов и acceptance criteria.

Архитектор в AI-native процессе пишет меньше низкоуровневого кода, но больше точной прозы. Он ревьюит diff, тесты, архитектурные границы и соответствие спецификации.

Agent Output Review — код агента требует такой же дисциплины, как PR человека

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

Код от агента нельзя принимать потому, что он компилируется. Нужны tests, evals, import boundaries, type checks, security review. Особенно важны scenario evaluations: система должна проходить реальные кейсы, а не только happy path.

AI-native организация выигрывает не там, где «все вайбкодят», а там, где есть сильные спецификации, маленькие итерации, автоматические проверки и архитектурное владение.

Ivory Tower Architect — архитектор в башне из слоновой кости

Человек рисует идеальный город на холме, но никогда не спускается посмотреть, где люди реально ходят.

Это антипаттерн ivory tower architect: решения принимаются вдали от кода, эксплуатации и команды. Диаграммы красивы, но implementation страдает. Лекарство простое: читать PR, смотреть инциденты, разговаривать с инженерами, самому проходить путь изменения.

Resume-driven Development и Cargo Cult

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

Resume-driven development выбирает технологии ради строки в CV. Cargo cult engineering копирует форму чужого решения без причины. NIH syndrome (Not Invented Here) заставляет писать своё там, где зрелый внешний инструмент лучше.

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

T-shaped / M-shaped Skills — учиться по системам, не по хайпу

Повар растёт не от просмотра рекламы ножей, а от понимания продуктов, тепла, времени и вкуса.

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

T-shaped skills дают глубину в одной области и ширину по соседним. M-shaped skills появляются у зрелого архитектора: несколько глубоких опор — данные, распределённость, безопасность, продукт, AI-инструменты.

Learning in Public — ускоряет зрелость

Когда объясняешь решение письменно, дырки в мышлении становятся видны раньше, чем в продакшене.

Learning in public — учиться открыто, письменно. Пиши ADR, RFC, engineering notes, post-mortems, короткие разборы решений. Учись у архитекторов сильнее тебя: не только что они выбрали, но как они рассуждали.

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

Карта курса: как всё связано

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

Мышление выбирает форму системы, данные и качество. Структура записывается в документы, качество проверяется безопасностью и эксплуатацией, а документы и риски убеждают бизнес. Всё вместе масштабируется в AI-native работу и личный рост.