Мнение Мартина Фаулера: архитектура, которая переживает модные стэки

Почему модные техстеки не гарантируют хорошую архитектуру

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

Проблема мышления «сначала стек»

Выбор стека в первую очередь толкает команды к решениям, которые эффектно выглядят на слайде, но не отвечают на реальные вопросы:

• Где границы?
• Что нужно менять часто?
• Что должно оставаться стабильным?

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

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

Практический вывод: инструменты ускоряют доставку, но не заменяют архитектурное мышление. Даже при современных подходах типа vibe-кодинга — когда вы быстро генерируете и итеративно дорабатываете через чат — те же вопросы остаются. Платформы вроде Koder.ai могут заметно ускорить сборку веба, бэкенда и мобильных приложений, но лучшие результаты получают команды, которые по-прежнему трактуют границы, владение и изменяемость как первоочередные вопросы (а не как то, что фреймворк волшебно решит).

Влияние Фаулера: ясность, прагматизм и время

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

На чем сосредоточится эта статья

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

Для кого это

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

Что на самом деле означает «программная архитектура» (без жаргона)

Программная архитектура — это набор решений, которые формируют систему так, что их трудно (и дорого) менять позже.

Это определение намеренно простое. Оно не требует специальных диаграмм или титула «архитектор». Речь о выборах, которые определяют, как ПО может расти, как команды могут работать и сколько будет стоить эксплуатация.

Архитектура — это не ваш техстек

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

• Выбор React vs Vue часто обратим.
• Решение «все записи идут через один сервис» намного труднее отменить.

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

Архитектура — это в основном компромиссы

Универсальной «лучшей» архитектуры не существует. Каждое крупное решение оптимизирует одни цели и нагружает другие:

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

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

Короткий пример: архитектурное решение vs выбор библиотеки

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

  Это влияет на деплой, владение данными, режимы отказов, мониторинг и координацию команд.

• Выбор библиотеки: «Используем библиотеку X для генерации PDF.»

  Полезно, но обычно заменяемо с ограниченным радиусом поражения.

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

Паттерны как инструменты: полезно, опционально и иногда вредно

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

Когда паттерны помогают

При грамотном применении паттерны дают команде общий словарь. Словами «strategy» или «repository» можно заменить длинное объяснение, что ускоряет ревью и снижает недопонимания.

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

Когда паттерны вредят

Типичная ошибка — карго-культ: применение паттерна потому что он популярен, потому что про него писали в книге или «так принято у нас». Это часто ведёт к переинженерии — лишним слоям, косвенным вызовам и абстракциям, которые не окупаются.

Ещё одна ловушка — «паттерн на всё». Когда для каждой мелочи придумывается именованное решение, кодовая база превращается в музей хитростей вместо инструмента для быстрой доставки и поддержки ПО.

Практический способ выбора

Начните с проблемы, а не с паттерна.

Спросите:

• Какое изменение мы хотим упростить?
• Какой риск мы уменьшаем?
• Какую сложность вводим?

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

Рефакторинг: привычка, сохраняющая архитектуру здоровой

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

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

Почему рефакторинг — это архитектурная деятельность

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

Здоровая архитектура — это когда:

• важные бизнес-правила не переплетены с деталями UI
• модули имеют чёткие обязанности
• зависимости направлены разумно

Рефакторинг — ежедневная работа по сохранению этих качеств.

Частые триггеры «пора рефакторить»

Обычно вы не ставите рефакторинг по календарю — вы делаете его, когда код начинает «возражать»:

• Дублирование: одно и то же правило реализовано в трёх местах и постепенно расходится
• Неясные границы: «всё касается всего», изменения рискованные
• Медленная доставка: простые запросы занимают дни, потому что каждое изменение вызывает сюрпризы

Когда это проявляется, архитектура уже страдает — рефакторинг это ремонт.

Как рефакторить безопасно (не ломая всё)

Безопасный рефакторинг опирается на привычки:

• Тесты, которые ловят непреднамеренные изменения поведения (особенно в бизнес-логике)
• Маленькие шаги: много небольших обратимых правок, а не один огромный рефакторинг
• Код-ревью: ещё один взгляд, чтобы заметить побочные эффекты и размывание объёма

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

Технический долг: как он накапливается и как его гасить

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

Преднамеренный vs случайный долг

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

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

Как долг тихо накапливается

Долг добавляется под обычным давлением:

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

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

Лёгкие способы управлять и гасить долг

Не нужен большой план, чтобы начать:

• Бюджетируйте время постоянно (например, небольшой процент каждой итерации)
• Отслеживайте горячие точки, а не всё подряд: фокус на коде, в котором вы чаще всего работаете и которого боитесь
• Гасите по кусочкам: сочетайте рефакторинг с работой над фичами, чтобы «проценты» перестали накапливаться

Если вы делаете решения по долгу видимыми (см. /blog/architecture-decision-records), скрытые затраты превращаются в управляемую работу.

Эволюционная архитектура: проектируйте для изменений, а не для уверенности

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

Что значит «эволюционная архитектура»

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

Малые релизы, реальные данные

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

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

Именно здесь полезны инструменты быстрой итерации — при условии, что у вас есть архитектурные «ограждения». Если вы используете платформу вроде Koder.ai для быстрой генерации и итераций фич, сочетайте скорость с устойчивыми границами модулей, хорошими тестами и частыми деплоями, чтобы не «быстро закодить себя в угол».

Фитнес-функции (простыми словами)

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

Фитнес-функции не обязаны быть сложными. Это могут быть простые метрики, тесты или пороги, отражающие то, что вам важно.

Примеры практических проверок

• Время сборки: проваливать pipeline, если цикл сборки/тестов превышает лимит (например, 10 минут). Медленные сборки отпугивают рефакторинг и безопасные изменения.
• Уровень ошибок: сигнализировать или блокировать выкатку, если в проде растёт уровень ошибок выше базовой линии.
• Сканирование безопасности: автоматически сканировать зависимости и контейнеры; проваливать сборку при известных критических уязвимостях.
• Совместимость API: контрактные тесты, чтобы новые релизы не ломали внешних клиентов или внутренних потребителей.

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

Микросервисы vs монолиты: выбирайте по ограничениям, а не по моде

Микросервисы — не знак инженерного престижа. Суть Фаулера проще: разделение системы на сервисы — это столько же организационный шаг, сколько технический. Если вашим командам нельзя владеть сервисом сквозь весь цикл (build, deploy, operate, evolve), вы получите сложность без преимуществ.

Три формы, три компромисса

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

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

Микросервисы дают каждому сервису собственный цикл деплоя и жизни. Это может дать независимые релизы и ясное владение — если организация к этому готова. Иначе это часто превращает «одну сложную проблему» в «десять сложных проблем».

Скрытые издержки, о которых забывают

У микросервисов есть накладные расходы, которые не видны на диаграммах:

• Деплои: больше pipeline-ов, версионирование, откаты и координация
• Наблюдаемость: распределённый трейсинг, корреляция логов, значимые метрики
• Нагрузка on-call: больше режимов отказов, больше алертов, больше playbook-ов
• Консистентность данных: сложнее транзакции, eventual consistency и хитрые отчёты

Практический эвристический подход

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

Границы, связанность и реальная стоимость зависимостей

Хорошая архитектура — не про количество сервисов, а про то, насколько хорошо можно изменить одну часть, не сломав три другие. Фаулер часто формулирует это как работу с сцепкой (coupling) и сцеплением по смыслу (cohesion) — насколько деталь «собрана вместе».

Coupling и cohesion без жаргона

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

В софте так же: связные модули владеют ясной задачей; слабо связанные модули общаются через простые и стабильные соглашения.

Как заметить нездоровую связанность

Нездоровая связанность обычно проявляется в расписаниях раньше, чем в коде. Признаки:

• Координированные релизы: «Мы не можем выпустить, пока команда B не выпустит.»
• Частые блокировки между командами: работа останавливается из-за того, что другой команде нужно что-то изменить первой.
• Эффект домино: мелкая фича требует правок во многих репозиториях или сервисах.

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

Ходы дизайна для снижения сцепки

Снижение сцепки не требует переписывания всего. Практичные шаги:

• Чёткие API и контракты: относитесь к интерфейсу как к продукту; держите его стабильным и хорошо именованным.
• Bounded contexts: решите, за что каждая область отвечает, включая правила и словарь.
• Модульность: даже в монолите модули с явными границами могут вести себя как «мини-сервисы» без операционного оверхеда.

Когда решения важны, фиксируйте их лёгкими заметками, например [/blog/architecture-decision-records], чтобы границы оставались осознанными.

Данные: самая сложная граница

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

Более здоровый подход — владение данными: одна система владеет набором данных и предоставляет доступ через API или события. Это делает зависимости видимыми и, значит, управляемыми.

Архитектура — это ещё и люди: команды формируют системы

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

Когда org-chart противоречит дизайну

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

Признаки несовпадения:

• Частые передачи работ («Команда A должна одобрить, затем команда B деплоит, затем команда C мониторит»)
• Неясное владение («Кто владеет этим эндпоинтом?» — «Не мы.»)
• Медленный отклик на инциденты, потому что алерты, логи и исправления пересекают несколько команд
• Дорожные карты, зависящие от синхронизированных релизов многих групп

Практические способы снизить трение

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

• Соотнесите модули/сервисы с командами: одна команда должна иметь возможность внести значимое изменение без координации с пятью другими.
• Уточните ответственность: определите, кто строит, запускает и улучшает компонент (включая on-call и операционный бюджет).
• Сократите передачи: предпочитайте интерфейсы, позволяющие командам двигаться независимо — стабильные контракты, чёткие API и общие стандарты там, где это помогает.

Быть реалистом по ограничениями

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

Делайте решения видимыми: простые ADR

Архитектура — это не только то, что вы строите, но и решения, которые вы принимаете по пути. Architecture Decision Records (ADRs) — короткие заметки, фиксирующие эти решения, пока контекст ещё свеж.

Что такое ADR (и что это не такое)

ADRs — это одностраничная заметка на вопрос: «Что мы решили и почему?» Это не длинный дизайн-док и не пропуск на согласование. Считайте его долговой памятью команды.

Что включать

Держите структуру простой, чтобы можно было быстро просмотреть. Лёгкий ADR обычно содержит:

• Решение: что вы выбираете (например, «Использовать модульный монолит для v1»).
• Контекст: какая проблема и какие были ограничения.
• Рассмотренные альтернативы: 2–3 реалистичные варианта.
• Последствия: компромиссы — что становится проще, что сложнее.
• Дата и статус: proposed/accepted/superseded.
• Владельцы: кто вел это решение (не «кого винить»).

Почему это окупается

ADRs ускоряют онбординг: новые коллеги видят логику, а не только результат. Они также предотвращают повторные дебаты: когда вопрос возвращается через месяцы, можно пересмотреть ADR и обновить его, а не заново всё обсуждать. Главное — делать компромиссы явными, чтобы при смене реальности можно было пересмотреть план.

Держите их лёгкими

Используйте простой шаблон, храните ADR рядом с кодом (например, в /docs/adr/) и стремитесь писать одну заметку за 10–20 минут.

# ADR 012: API versioning strategy
Date: 2025-12-26
Status: Accepted
Owners: Platform team

Context:
We need to evolve public APIs without breaking partners.

Decision:
Adopt URL-based versioning (/v1/, /v2/).

Alternatives:
- Header-based versioning
- No versioning; rely on backward compatibility

Consequences:
+ Clear routing and documentation
- More endpoints to support over time

Если ADR ощущается как бюрократия — сокращайте его, но не отказывайтесь от практики.

Непрерывная доставка и обратная связь: двигатель эволюции

Архитектура не «остается хорошей», потому что кто-то однажды нарисовал диаграмму. Она остаётся хорошей, когда систему можно безопасно менять малыми шагами под реальной нагрузкой. Поэтому CI/CD и быстрые петли обратной связи так важны: они превращают эволюцию из рискованного события в нормальную привычку.

CI/CD делает рефакторинг практичным

Рефакторинг проще, когда изменения маленькие и обратимы. Здоровый CI/CD pipeline поддерживает это, автоматически собирая, тестируя и валидируя каждое изменение до попадания к пользователям. Когда pipeline внушает доверие, команды могут непрерывно улучшать дизайн, а не ждать «большого рефактора», который никогда не выйдет в прод.

Качество, которое облегчает изменения (а не бюрократию)

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

• Автотесты (unit + integration) — чтобы поведение оставалось стабильным при изменениях внутренних частей
• Статический анализ — для раннего обнаружения рисковых паттернов (сложность, небезопасные вызовы, проблемы с зависимостями)
• Проверки безопасности (сканирование зависимостей, базовый SAST) — чтобы не допускать «сюрпризных» уязвимостей

Цель — не идеальность; цель — повысить стоимость ломания и снизить стоимость безопасных улучшений.

Наблюдаемость как архитектурная обратная связь

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

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

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

Безопасный релиз: выкатывайте без страха

Эволюция требует частых релизов, поэтому нужны «эмergency-выходы». Фича-флаги позволяют разъединить деплой и релиз. Canary-релизы уменьшают радиус падения, выкатывая только небольшой процент. Чёткая стратегия отката (включая работу с базами) превращает провалы в восстанавливаемые события.

Если платформа приложения поддерживает snapshot-и откат (например, Koder.ai), это усиливает тот же принцип на уровне доставки продукта: двигайтесь быстро, но держите обратимость и безопасность операций по умолчанию.

Вместе CI/CD и обратная связь создают систему, которая может эволюционировать непрерывно — именно такую архитектуру, которая переживает тренды.

Практический чеклист, чтобы применить идеи Фаулера в этом квартале

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

Быстрый чеклист (используйте при планировании)

• Ясность: Может ли новый коллега объяснить основные обязанности системы на одной странице? Если нет — добавьте краткий README для каждой крупной области и опишите «форму» системы.
• Границы: Есть ли у модулей/сервисов чёткое владение и назначение, или они делят базы данных, «утилитарные» бакеты и «бог-пакеты»? Выберите одну границу для укрепления.
• Тесты как страховка: Есть ли быстрые тесты, которые позволяют рефакторить без страха? Приоритет — тонкий слой ценного покрытия вокруг наиболее изменяемого кода.
• Деплой: Можно ли деплоить мелкие изменения часто? Если релизы мучительны, сначала сделайте деплой банальным, прежде чем добавлять архитектурную сложность.
• Владение: Понятно ли, кто за что отвечает? Соотнесите кодовые границы с командными, где это возможно, и сделайте отображение явным.

План улучшений на 30/60/90 дней

Следующие 30 дней: Выберите одну «горячую точку» (частые изменения, инциденты). Добавьте набор тестов, упростите одну цепочку зависимостей и начните писать лёгкие заметки о новых решениях.

К 60 дням: Отрефакторьте одну проблемную стыковку: извлеките модуль, определите интерфейс или изолируйте инфраструктурную часть (например, слой хранения или messaging) за границей. Уменьшите «радиус поражения» изменений.

К 90 дням: Улучшите цикл доставки. Стремитесь к меньшим PR, более быстрым сборкам и предсказуемому ритму релизов. Если вы рассматриваете микросервисы, докажите необходимость: покажите, что граница не может быть управлена внутри существующего кода.

(Если цель — просто выпускать больше продукта с меньшим количеством передач, подумайте, где автоматизация поможет. Для некоторых команд чат-ориентированный workflow сборки вроде Koder.ai — с режимом планирования, экспортом исходников, деплоем/хостингом, пользовательскими доменами и уровнями от бесплатного до enterprise — может сократить механическую нагрузку, пока вы фокусируетесь на границах, тестах и операционной обратной связи.)

Измеряйте результаты, а не усилия

Отслеживайте несколько сигналов ежемесячно:

• Lead time от коммита до продакшена
• Change failure rate (откаты, хотфиксы)
• Объём инцидентов и повторяющиеся причины

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

Стэки будут меняться. Фундаментальные вещи — ясные границы, дисциплина рефакторинга и быстрая обратная связь — остаются.