17.08.2026

RDD — Risk Driven Development

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

Уровень применения: архитектура и проект (оценка и приоритизация архитектурных усилий на уровне системы в целом).

Статус: нишевый (George Fairbanks, 2010; развит в практике архитектуры как «risk-driven approach»).

Не путать с: Readme Driven Development (то же сокращение RDD, но движущая сила — документация: сначала README, описывающий продукт, потом код; риски здесь ни при чём). Это критическая дизамбигуация: см. раздел «Общее» ниже. В Risk-Driven Development движение идёт от реестра рисков, а не от текстов.

Общее

Risk Driven Development (RDD) — подход к разработке и проектированию программных систем, при котором объём, глубина и направленность архитектурных усилий определяются рисками проекта, а не полнотой модели, стандартами документации или представлением о «правильной» архитектуре самой по себе. Вместо вопроса «какой должна быть архитектура?» RDD ставит вопрос «сколько архитектуры достаточно?» — и отвечает на него операционально: ровно столько, сколько нужно, чтобы идентифицированные риски были сняты или снижены до приемлемого уровня. Не больше и не меньше.

Подход сформулирован Джорджем Фэрбенксом (George Fairbanks) в книге Just Enough Software Architecture: A Risk-Driven Approach (2010). Книга выросла из наблюдения, знакомого любому практикующему архитектору: индустрия колеблется между двумя симметричными провалами. Первый — архитектура «на всякий случай»: полные модели, слои, абстракции и обобщения, значительная часть которых никогда не понадобится, но всё это нужно сопровождать. Второй — «архитектуры нет вообще»: код пишется сразу, структурные решения принимаются имплицитно и задним числом, а их последствия обнаруживаются в продакшене. Фэрбенкс предложил третий путь — измерять потребность в архитектуре рисками: там, где вероятность и цена неудачи высоки, проектировать глубоко и проверять; там, где риска нет, — сознательно не тратить усилия.

Предыстория: почему вопрос «сколько архитектуры» вообще встал

Вопрос о дозировке архитектурных усилий старше самой RDD, и без него подход не читается. К 1970–80-м в индустрии доминировала каскадная схема с её ставкой на большое проектирование вперёд (big design up-front, BDUF): сначала полная спецификация требований, затем полная архитектурная модель, и только потом код. Для тяжёлых документоёмких процессов (характерный пример — RUP в «тяжёлой» конфигурации) «хорошая архитектура» измерялась полнотой моделей. Провал этой ставки был двояким: upfront-модели описывали систему, которой ещё не существовало, и потому систематически промахивались — требования успевали измениться, пока проектировали; а структура, спроектированная «на все случаи», не соответствовала реальным нагрузкам: абстракции строились под сценарии, которые не наступали, тогда как настоящие проблемы всплывали только в коде и продакшене.

Существенная часть интеллектуальной базы для критики обеих крайностей заложена Фредериком Бруксом. В «Мифическом человеко-месяце» (1975) он аргументировал, что концептуальная целостность — решающее соображение при проектировании: система должна выглядеть спроектированной одной головой, а не комитетом, и ради этой целостности стоит отбрасывать даже удобные фичи, портящие форму. В эссе «No Silver Bullet» (1986) Брукс разделил сложность ПО на существенную (присущую самой предметной области) и случайную (привнесённую инструментами и неудачными решениями) и показал, что ни одна технология не устраняет существенную сложность — её можно только аккуратно структурировать. Из этих работ следует вывод, неудобный для обеих крайностей: проектировать необходимо (концептуальная целостность сама не возникнет), но спроектировать всё заранее невозможно (существенная сложность раскрывается только в работе с кодом и пользователями). BDUF нарушает вторую половину вывода, «архитектуры нет» — первую.

Агильный поворот конца 1990-х — 2000-х качнул маятник в противоположную сторону: «архитектура возникает сама» (architecture emerges), «работающий код важнее исчерпывающей документации». Для небольших систем с короткой жизнью это действительно работало; для долгоживущих сложных систем обернулось симметричным провалом, у которого появилось собственное имя — big ball of mud (Брайан Фут и Джозеф Йодер, «Big Ball of Mud», 1999): систем без выраженной структуры, в которых каждое следующее изменение дороже предыдущего, а через пару лет команда обнаруживает, что не может менять код безопасно. И снова Брукс, теперь в другом чтении: отказ от проектирования не отменяет архитектурных решений — они продолжают приниматься, но имплицитно, случайно и без ответственности за последствия.

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

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

Ключевой ход книги — переопределение роли архитектурных техник (modeling techniques). У Фэрбенкса техники — это инкапсуляция и сокрытие информации, сегрегация интерфейсов, слоистость, инверсия зависимостей, паттерны, представления (views) и т. д. — и они трактуются не как самоцель и не как признак «взрослого» процесса, а как инструменты снижения конкретных рисков. Техника применяется тогда и только тогда, когда она закрывает риск из реестра; «применять все техники всегда» так же ошибочно, как «не применять никаких».

Исторически RDD — прямой наследник спиральной модели Барри Боэма (Barry Boehm, 1986), каждая итерация которой явно управляляется рисками: спирали проходят через определение целей, оценку рисков, инженерию и планирование следующего витка. Фэрбенкс перенёс ту же логику с уровня процесса разработки на уровень архитектурного проектирования: не «построим полную архитектуру к концу анализа», а «на каждом витке спирали спроектируем ровно ту часть, которую требуют актуальные риски, и проверим, что они сняты». Тем самым RDD хорошо ложится и на итеративные процессы (см. SDLC, спиральную модель), и на Agile-разработку, где «большое проектирование вперёд» (BDUF) противопоказано, а управляемая архитектурная дисциплина — необходима.

Генеалогия подхода глубже одной отсылки. Боэм сформулировал спиральную модель как реакцию на два симметричных провала — каскада (недооценка неопределённости) и свободного прототипирования (недооценка дисциплины): каждый виток спирали начинается с явного перечня наибольших оставшихся рисков (позже Боэм оформил это практикой «top-10 risk list»), и успех витка измеряется тем, насколько эти риски снижены, а не количеством произведённого кода. Фэрбенкс сохранил эту механику, но сменил масштаб: у Боэма риск управляет выбором работ следующей итерации процесса, у Фэрбенкса — выбором глубины проектирования внутри работы. Спиральная модель отвечает, что делать следующим витком; RDD — сколько и какой архитектуры внутри этого витка. Практически подходы усиливают друг друга: спираль без риск-ориентированного проектирования рискует потратить виток на работы без проектной глубины; RDD без спиральной логики итераций рискует выродиться в разовое упражнение на старте проекта.

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

От RDD как инженерного подхода следует отличать расхожее употребление словосочетания «risk-driven» в широком менеджерском смысле (приоритизация backlog’а по рискам, риск-ориентированное тестирование). В статье RDD рассматривается в каноническом значении Фэрбенкса — как risk-driven architectural design, риск-ориентированное принятие архитектурных решений.

Дизамбигуация: RDD — Risk и RDD — Readme

Самая частая путаница в обсуждениях «RDD» — совпадение аббревиатур двух неродственных практик: Risk Driven Development (Фэрбенкс, 2010) и Readme Driven Development (популяризировано Заком Холманом, Zach Holman, ~2011). Разведём их явно:

Ось Risk Driven Development Readme Driven Development
Движущая сила Риски: что может пойти не так в системе Документация: README как спецификация продукта
Основной вопрос «Сколько архитектуры достаточно?» «Что именно мы строим и зачем?»
Уровень применения Архитектура и проект Продукт и требования
Основной артефакт Реестр рисков + архитектурные решения README, пишущийся до кода
Что даёт Фокус усилий там, где цена неудачи высока Прозрачность замысла до первой строки кода
Происхождение Fairbanks, Just Enough Software Architecture (2010) Zach Holman, доклад/эссе (~2011), полушутливая практика

Подходы ортогональны и даже совместимы: можно описать продукт в README (readme-driven) и проектировать его архитектуру от реестра рисков (risk-driven). Но смешивать их в одном термине нельзя: когда в обсуждении звучит «RDD», первое, что стоит уточнить, — о рисках идёт речь или о документации. Статья о Readme Driven Development готовится в этой же серии базы знаний; далее под RDD везде понимается Risk Driven Development.

Ключевые принципы

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

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

Явная работа с рисками (реестр рисков). Риски фиксируются письменно — в виде списка или реестра с вероятностью, последствиями и статусом. Проблема: риски, живущие «в головах», либо забываются, либо не разделяются командой — каждый понимает под угрозой своё. Явный реестр делает разногласия видимыми: их можно обсудить, приоритизировать и перепроверить. Реестр — живой артефакт: риски добавляются, закрываются и переоцениваются на каждом витке. Минимальная запись — четыре поля: формулировка, вероятность, последствия, статус; запись «нагрузка ×10 к чёрной пятнице ляжет авторизацию: вероятность высокая, последствия высокие, открыт» уже пригодна и для приоритизации, и для последующей проверки снятия.

«Ровно столько, сколько нужно» (just enough). Архитектура строится не полностью, а до состояния, в котором покрыты актуальные риски. Как только топ-риски закрыты проектированием и проверкой, проектирование останавливается. Проблема: и полнота («модель всего»), и её отсутствие («код сразу») — дороги, каждая по-своему. Just enough — операциональный критерий остановки, которого у классической архитектурной деятельности нет: там «достаточность» определяется планом или вкусом архитектора, здесь — реестром. Практически это выглядит так: если топ-риск витка — интеграция с платёжным провайдером, достаточно спроектировать порт и один адаптер под действующего провайдера; строить на этом основании «обобщённую платформу интеграций на десять провайдеров» — перерасход, которого реестр не заказывал.

Риски определяют выбор техник моделирования. За каждым типом риска стоят свои архитектурные техники; выбор техники — следствие риска, а не моды. Проблема: техники (слои, микросервисы, CQRS, событийные шины) часто применяются потому, что «так делают» или «интересно попробовать», — без связи с угрозами. RDD переворачивает порядок: сначала риск («не сменим провайдера без переписывания ядра»), затем техника (инкапсуляция, порты и адаптеры, антикоррупционный слой). Соответствие «риск → техника» — операциональное ядро подхода (см. таблицу в разделе «Как это работает»). Контрпример из практики: команда внедряет CQRS и event sourcing, потому что «на конференции показали», — при пустом реестре; реальный риск (нет навыка эксплуатации событийных систем) не только не закрыт, но и усилен собственным решением.

Over-engineering и under-engineering — симметричные провалы. РDD вводит пару зеркальных ошибок и требует видеть обе. Over-engineering — архитектуры больше, чем требуют риски: лишние уровни абстракции, «масштабируемость на миллиард» у продукта с тысячей пользователей, обобщение на случаи, которые не наступят. Расплата — медленная разработка, сложность сопровождения, размывание простой логики. Under-engineering — риски не покрыты: структурные решения не приняты вовсе, и система падает там, где падение было предсказуемо. Расплата — переделки, инциденты, «большой переписывательный» проект через год. RDD — это управление положением между этими провалами: явный реестр позволяет аргументированно отвечать и на «зачем ты это проектируешь?» (какой риск закрываем), и на «почему это не спроектировано?» (какого риска нет). Пример over-engineering: слой абстракций над базой данных «на случай смены СУБД», не переживший бы ни одной реальной миграции, но усложнивший каждый запрос. Пример under-engineering: отсутствие идемпотентности в платёжном API, потому что «дубли редки», — до первого повторного клика пользователя в зоне неустойчивой связи.

Принципы — система, а не меню: реестр без пропорциональности превращается в бюрократию; пропорциональность без соответствия «риск → техника» вырождается в интуицию; just enough без явной пары «over/under» не имеет критерия самоконтроля. Частичное применение создаёт видимость процесса; связное — даёт заявленный эффект: усилия концентрируются там, где ставка высока.

Три вопроса Фэрбенкса

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

  1. Какие риски у проекта? Что может пойти не так — в функционировании, в атрибутах качества, в интеграциях, в данных — и насколько каждый отказ вероятен и дорог. Продукт шага — пополненный реестр с приоритетами. Типовая ошибка шага — формулировки-лозунги («проблемы с безопасностью») вместо проверяемых утверждений («эндпоинт списания доступен из интернета без авторизации и не логируется»).
  2. Какие архитектурные техники закрывают эти риски? Для каждого приоритетного риска — какие техники из каталога действительно его снижают, а какие лишь создают видимость активности. Продукт шага — отображение «риск → техника» на предстоящий виток. Типовая ошибка — выбор техники по моде («микросервисы решают всё»), не связанный с конкретной угрозой.
  3. Сколько усилий достаточно? Насколько глубоко применять выбранную технику: хватит ли схемы на доске или нужна формализованная модель с несколькими представлениями; хватит ли эвристической оценки риска или нужен количественный анализ; нужен ли прототип или достаточно walkthrough’а. Продукт шага — явное решение об объёме усилий. Типовая ошибка — незаметный дрейф к BDUF, когда каждая техника применяется «на полную глубину», потому что никто не спросил, сколько достаточно.

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

Как это работает

RDD исполняется как повторяющийся цикл, а не разовое мероприятие. Виток цикла:

  1. Идентифицируй риски. Команда перечисляет, что может пойти не так и стоить дорого: в функциональности, в качестве атрибутов (производительность, безопасность, изменяемость), в интеграциях, в данных. Каждый риск формулируется проверяемо («система не обработает 1000 RPS на пике», «смена провайдера SMS-рассылок затронет ядро»), а не расплывчато («проблемы с масштабированием»).
  2. Приоритизируй. Риски ранжируются по произведению вероятности на последствия. Инструментарий — от простой шкалы «высокий/средний/низкий» до численных оценок; точность формул менее важна, чем разделяемое командой упорядочение. Наверх выходят несколько рисков, определяющих работу витка.
  3. Выбери архитектурные техники под топ-риски. Для каждого приоритетного риска из каталога техник выбираются те, что его закрывают. Это ядро процесса: соответствие «риск → техника» (таблица ниже) превращает абстрактную заботу о качестве в конкретные проектные действия.
  4. Построй и проверь. Техники применяются в проектировании и коде; снятие риска верифицируется — прототипом, нагрузочным тестом, метрикой, разбором модели. Риск, не подтверждённый проверкой, остаётся открытым.
  5. Повтори. Реестр пересматривается: часть рисков закрыта, часть переоценена, появились новые. Следующий виток проектирует следующую порцию архитектуры. Так система постепенно обрастает «плотью» ровно там, где это оплачено рисками.

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

       ┌─────────────────────────────────────────────────────────────┐
       ▼                                                             │
   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌─────────────────┴┐
   │ Определи │    │Приоритизи│    │  Выбери  │    │  Спроектируй и   │
   │   риски  │ →  │руй риски │ →  │  техники │ →  │  построй         │
   └──────────┘    └──────────┘    └──────────┘    └──────────┬───────┘
                                                              │
                             ┌────────────────────────────────┘
                             ▼
                          ┌─────────────┐ ── НЕ СНЯТ ▶┌──────────────────┐
                          │   Проверь   │             │  Переоцени риск, │
                          │   снятие    │             │  усиль или смени │
                          │   рисков    │             │     технику      │
                          └──────┬──────┘             └──────────────────┘
                                 │ СНЯТ
                                 ▼
                   закрыть в реестре → следующий виток

Цикл повторяется на каждом витке планирования — спринте, витке спирали, инкременте, — а не исполняется один раз на старте проекта. Именно повторяемость отличает RDD от «провели сессию по рискам и забыли»: реестр живёт, приоритеты пересматриваются по мере поступления новых знаний, и архитектура нарастает порциями, каждая из которых оплачена актуальной позицией реестра. В терминах трёх вопросов Фэрбенкса (раздел «Ключевые принципы») шаги «определи → приоритизируй → выбери техники» реализуют вопросы 1–2, шаг «спроектируй» распределяет глубину усилий по вопросу 3, а шаг «проверь» замыкает цикл фактами — единственной валютой, которую реестр принимает как доказательство снятия.

Сводное соответствие шагов цикла, трёх вопросов Фэрбенкса, артефактов и типовых ошибок витка:

Шаг цикла Вопрос Фэрбенкса Артефакт на выходе Типовая ошибка шага
Определи риски 1. «Какие риски у проекта?» Пополненный реестр Лозунги вместо проверяемых формулировок
Приоритизируй 1. «Какие риски у проекта?» — упорядочение Топ-риски витка Псевдоточная квантификация вместо разделяемого упорядочения
Выбери техники 2. «Какие техники их закрывают?» Отображение «риск → техника» Техника по моде, без связи с угрозой
Спроектируй и построй 3. «Сколько усилий достаточно?» Модели и код витка Дрейф к BDUF: полная глубина без запроса реестра
Проверь снятие 3. «Сколько усилий достаточно?» — критерий остановки Факты: тесты, стенды, ревью «Проверено» без проверки; риск закрыт на словах

Ключевое соответствие «тип риска → архитектурная техника» — операциональная таблица RDD. Приведённый ниже вариант охватывает шесть наиболее частых категорий технических рисков (строки упорядочены по типам, а не по важности — важность каждый проект определяет сам):

Тип риска Что может пойти не так Архитектурные техники (2–3 на риск) Что НЕ делать (типовая ошибка)
Масштабируемость Система не выдержит рост нагрузки; горизонтальное масштабирование невозможно Моделирование нагрузки и нагрузочные тесты; шардинг и репликация данных; асинхронная обработка через очереди «Микросервисы ради масштабируемости» без измеренного профиля нагрузки; шардинг там, где хватило бы индексов и кэша
Безопасность Утечка данных; несанкционированный доступ; компрометация компонента Моделирование угроз (threat modeling, STRIDE); разграничение зон доверия и defence in depth; аутентификация/авторизация и шифрование на границах Доверяться «безопасности по умолчанию» фреймворка; хранить секреты в репозитории; откладывать моделирование угроз «до стабилизации фич»
Производительность Деградация отклика под реальным профилем запросов Профилирование и бенчмарки критических путей; кэширование и оптимизация доступа к данным; выделение «горячих» путей в отдельные компоненты Оптимизировать без профилирования (классическая преждевременная оптимизация); масштабировать железом то, что лечится алгоритмом
Интеграция Замена или сбой внешней системы разрушит ядро Антикоррупционный слой и порты-адаптеры; контракты API (OpenAPI, схемы событий) и контрактное тестирование; брокеры сообщений для развязки по времени Строить «универсальную платформу интеграций» под одного действующего провайдера; допускать протекание моделей внешней системы в домен
Доступность Отказ одного узла/зависимости останавливает сервис Избыточность и репликация (устранение единой точки отказа); паттерны устойчивости (circuit breaker, timeout/retry, graceful degradation); health checks и мониторинг Multi-region без сформулированных RTO/RPO; retry-политики без таймаутов и без ограничения числа попыток
Эволюционность Каждое изменение требований требует дорогой перестройки Инкапсуляция и сокрытие информации; инверсия зависимостей и явные границы модулей; ADR для фиксации решённых альтернатив Абстракции «под смену СУБД или языка», не подтверждённые риском; спекулятивные обобщения «на будущее»

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

Минимальный пример витка

Команда запускает сервис онлайн-записи, интегрированный с внешним платёжным провайдером и SMS-шлюзом. Горизонт — год, ожидаемый рост нагрузки — ×10.

Виток 1. Реестр: (а) «смена тарифов провайдера заставит менять платёжную логику — вероятность высокая, последствия высокие»; (б) «нагрузка ×10 ляжет» — вероятность средняя, последствия высокие; (в) «не успеем с UI» — вероятность средняя, последствия низкие. Приоритет — (а) и (б). Техники: для (а) — инкапсуляция платежей за портом-адаптером и антикоррупционный слой (риск интеграции); для (б) — модель нагрузки, нагрузочный тест прототипа на целевой профиль, асинхронная очередь подтверждений (риск масштабируемости). Проверка: тест прототипа показывает запас по нагрузке; смена провайдера «на бумаге» затрагивает только адаптер. Риск (в) сознательно не оплачивается архитектурой — закрывается управленчески.

Виток 2 (через квартал). Реестр пересмотрен: риск (а) частично снят, но SMS-шлюз показал нестабильность — в реестр добавлен риск доступности, под него выбираются circuit breaker и retry-политика. UI-риск закрыт и забыт.

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

Сквозной пример: платёжный шлюз

Более развёрнутый проход цикла — проект, в котором топ-риск лежит в плоскости безопасности. Команда из шести человек строит платёжный шлюз: приём карточных платежей для нескольких интернет-магазинов, горизонт жизни — годы, действует регуляторика PCI DSS.

Виток 1, шаг 1 — идентификация. Брейншторм по категориям таблицы выше даёт девять сырых записей; после склейки дубликатов в реестре остаётся семь. Топ-3: (1) «компрометация карточных данных при утечке из нашей инфраструктуры — вероятность средняя, последствия катастрофические (штрафы PCI DSS, отзыв партнёрств, репутационный удар)»; (2) «пиковая нагрузка в распродажи (×20 от средней) ложит авторизацию — вероятность высокая, последствия высокие»; (3) «смена эквайрера потребует переписывания бизнес-логики — вероятность средняя, последствия средние».

Виток 1, шаг 2 — выбор техник. Для риска (1) назначаются моделирование угроз (STRIDE по границам доверия) и defense in depth: токенизация карточных данных на входе (внутри системы живут только токены), сегментация сети, шифрование трафика и хранения, разграничение доступа и аудит действий. Для риска (2) — модель нагрузки, нагрузочный стенд и асинхронная очередь между приёмом платежа и уведомлениями магазинов. Для риска (3) — инкапсуляция эквайрера за портом-адаптером.

Виток 1, шаг 3 — сколько усилий. Глубина распределяется по приоритету: под безопасность выполняется полная модель угроз с формализованными границами доверия — документируем и отдаём на внешнее ревью; под нагрузку достаточно модели уровня «какие узлы сколько RPS держат» плюс прототип критического пути на стенде; под смену эквайрера — один интерфейс и соглашение об адаптерах, без попыток предугадать «всех возможных провайдеров». Админка и витрины магазинов на этом витке не проектируются вовсе: их риски в топ-реестр не вошли.

Виток 1, шаг 4 — проверка. Модель угроз на внешнем ревью вскрывает две пропущенные зоны — логирование карточных номеров в trace-логах и кэш сессий, содержащий данные карты; обе закрываются в том же витке. Нагрузочный стенд показывает, что синхронная авторизация держит ×8 от целевого профиля — команда вводит очередь и пул воркеров, повторный тест даёт ×24, риск (2) закрывается. Риск (3) проверяется walkthrough’ом: сценарий «смена эквайрера» на бумаге затрагивает только адаптер и конфигурацию.

Виток 2 (через месяц). Реестр пересматривается: риски (1) и (2) сняты и переведены в режим мониторинга, (3) закрыт частично. Наверх выходят угрозы, обнаруженные в ходе витка 1: рассогласование данных при сбое между шагами платежа (техники: идемпотентные ключи, транзакционный outbox) и деградация магазина-партнёра при сбое шлюза (circuit breaker, таймауты, graceful degradation). Архитектура нарастает следующими кусками — каждый оплачен позицией реестра.

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

Сквозной пример показывает главную пропорцию RDD: глубина проектирования следует за риском, а не за функцией. Безопасность, будучи самым дорогим сценарием отказа, получила наибольшие усилия — при том, что это «нефункциональное» требование, которое в фича-ориентированном плане не имело бы собственного голоса. Одновременно видно, что цикл не статичен: проверка первого витка не только закрыла риски, но и породила новые — для RDD это нормальный режим работы, а не сбой процесса.

Ещё одно свойство, не очевидное снаружи: RDD не гарантирует отсутствия архитектурных ошибок. Он гарантирует другое — что известные команде дорогие ошибки были рассмотрены до кода и что на архитектуру потрачено сознательно выбранное количество усилий. Неизвестные риски (unknown unknowns) остаются территорией итеративной разработки, эволюционной архитектуры и проектирования систем как дисциплины.

Влияние на команду и процесс

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

Реестр рисков как артефакт командной работы. Центральный организационный сдвиг: реестр рисков становится общим, живым и доступным артефактом — как backlog, только про угрозы. Риски предлагают все (разработчики, QA, ops, аналитики), приоритизация обсуждается явно, закрытие рисков демонстрируется проверкой. Проблема, которую это решает: в традиционном процессе архитектурные опасения высказываются устно на встречах и растворяются; в RDD у каждого опасения есть идентификатор, приоритет и статус. Практический эффект — разрешение вечного спора «сколько проектировать»: не вкусом и не громкостью голоса, а ссылкой на позицию в реестре.

Минимальный формат записи риска, достаточный для старта:

R-07  Смена тарифов платёжного провайдера потребует правки ядра
      Вероятность: высокая   Последствия: высокие
      Техника: порт-адаптер + антикоррупционный слой
      Проверка: walkthrough «смена провайдера» затрагивает
                только адаптер и конфигурацию
      Статус: открыт → снят 2026-08-17 (см. ADR-012)

Формат важнее инструмента: таблица в вики, лист в issue-трекере или YAML-файл в репозитории равно пригодны, пока записи проверяемы, у реестра есть владелец и он живёт вместе с кодом.

Роль архитектора = управление рисками. RDD переописывает саму роль: архитектор — не «человек, рисующий самую полную модель», а управляющий портфелем рисков. Его работа — выуживать риски из команды и стейкхолдеров, приоритизировать, подбирать техники, добиваться проверки и честно сообщать, какие угрозы приняты (никак не закрыты). Это же задаёт честную метрику качества архитектора: не «сколько моделей нарисовал», а «какая доля топ-рисков закрыта проверяемо и сколько усилий на это ушло». Для распределённых команд «архитектурных» ролей это особенно ценно: логика решений перестаёт быть личным знанием и становится разделяемой.

Связь с риск-менеджментом проекта (PMBoK). Технический реестр RDD естественно стыкуется с проектным риск-менеджментом, известным по PMBoK (идентификация → качественный и количественный анализ → планирование ответов → мониторинг). Отличие в объекте и инструментах: PMBoK-процесс работает по всему пространству проектных угроз (сроки, бюджет, ресурсы) с управленческими ответами, RDD — по техническим угрозам с архитектурными техниками. На практике реестры стоит вести совместно: технический риск «не выдержим нагрузку» имеет прямое проектное следствие «сорвём запуск», и наоборот — проектное давление «закрыть доступ к эксперту» обостряет технический риск неправильной доменной модели. Команда, ведущая один реестр с двумя разрезами, получает целостную картину.

Технические и проектные риски: правило разграничения. Практический тест различения прост: технический риск снимается архитектурной техникой, проектный — управленческим действием. «Не выдержим нагрузку» — технический (снимается архитектурой и стендом); «уходит ключевой разработчик доменной логики» — проектный (снимается преемственностью и документированием, хотя и обостряет технический риск неверной модели); «сорвём запуск из-за несогласованных требований» — проектный, но его техническая проекция «архитектура не поддержит поздние изменения требований» — уже территория RDD. Один и тот же отказ часто имеет оба измерения, и тогда нужны оба ответа — архитектурный и управленческий. Команде стоит явно маркировать разрез в общем реестре: это предотвращает самую частую путаницу, когда проектный риск «пытаются снять» архитектурой (лишние слои не вернут ушедшего эксперта) или наоборот, технический риск — наймом и переговорами вместо изменения структуры.

Влияние на ADR. RDD придаёт Architecture Decision Records недостающий критерий содержательности: каждое архитектурное решение фиксируется со ссылкой на риск, который оно снимает. Секция «контекст» ADR наполняется риском и его оценкой; секция «последствия» включает, как будет проверяться снятие. Это отсекает решения-без-причины («введём слой, потому что так положено») и делает набор ADR самодостаточным аудиторским следом архитектуры: почему проектировали именно это и именно так. Обратное тоже работает: риск, который не удаётся связать ни с одним решением, — сигнал либо дыры в архитектуре, либо лишнего риска в реестре.

Пример записи ADR с полем «снимаемый риск»:

# ADR-014: токенизация карточных данных на границе шлюза

Статус: принято (2026-08-17)

Снимаемый риск: R-01 «компрометация карточных данных при утечке
из нашей инфраструктуры» (вероятность: средняя; последствия:
катастрофические — штрафы PCI DSS, отзыв партнёрств)

Контекст: шлюз принимает, хранит и передаёт карточные данные;
значительная часть инфраструктуры находится вне периметра PCI.

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

Проверка снятия: повторная модель угроз (STRIDE) после внедрения;
внешний аудит сегмента; автотест, сканирующий логи на PAN-паттерны.

Последствия: + утечка внутренней инфраструктуры больше не раскрывает
данные карт; − появляется зависимость от доступности токенизатора;
миграция уже накопленных данных — отдельный виток реестра.

Планирование и оценка. Риск-ориентированное проектирование меняет форму ранних итераций: вместо «сначала функциональность, потом наведём порядка» команда закладывает в план витки снятия топ-рисков — включая риски, лежащие вне видимой функциональности (нагрузка, безопасность, интеграции). Для руководителя это означает: часть velocity первых спринтов уходит на «невидимые» работы — их ценность затем можно показать закрытыми рисками, а не демонстраемыми фичами. Отчитываться о них лучше всего самим реестром: «было 8 критических рисков — осталось 2» — понятная и честная метрика прогресса.

Риски как work items в спринте. В терминологии Скрама RDD добавляет к product backlog’у параллельный бэклог рисков: топ-риски становятся задачами спринта — с оценкой, владельцем и критерием готовности, выраженным через проверку («риск R-07 считается снятым, когда walkthrough проходит без правок ядра»). На planning’е команда явно распределяет мощность спринта между функциональностью и снятием рисков; рабочая эвристика для рискованного проекта на старте — 20–30% мощности на риск-работы с последующим снижением по мере выгорания реестра. Прогресс отслеживается как risk burn-down — зеркало классического burndown-чарта, где по оси откладываются открытые риски или их взвешенная сумма. Это же дисциплинирует спайки: timeboxed-исследование в RDD всегда привязано к конкретному риску и завершается вердиктом («риск снят / подтверждён и переоценён / не воспроизведён»), а не общим заключением «мы изучили технологию».

Дизайн дискуссий становится короче и предметнее. Споры «делать микросервисы или монолит», «нужен ли CQRS», «сколько слоёв» в RDD автоматически переформулируются в «какой риск мы закрываем и какие затраты приемлемы». Дискуссии без риск-обоснования закрываются решением «не делаем — риска нет»; дискуссии с риск-обоснованием получают проверяемый критерий успеха. Культурный эффект: меньше религий, больше инженерии.

Преимущества

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

«Just enough» — архитектура без over-engineering. Явный критерий остановки («топ-риски закрыты — проектируем дальше код») систематически отсекает избыточную архитектуру: лишние слои, спекулятивные абстракции, «масштабируемость на вырост» без обоснования. Это прямой вклад в контроль технического долга: долга не возникает, если сложности не строили. Механизм прост: у классического проектирования нет внешнего критерия остановки, и оно тянется до исчерпания времени или терпения; в RDD остановку заказывает реестр. Пример: стенд показал запас ×24 к целевому профилю — проектирование масштабируемости останавливается, дальнейшее шардирование обоснования не получает.

Явное обоснование решений. Каждое архитектурное решение в RDD имеет причину — риск с оценкой вероятности и последствий, зафиксированный в реестре и ADR. Это окупается при эволюции системы: последователи понимают, что решение закрывало и перестало ли оно быть актуальным, — вместо слепого следования «так исторически сложилось». Пример: команда-преемник находит в ADR запись «антикоррупционный слой снимает риск R-07 смены провайдера» и может проверить, жив ли этот риск; если провайдер зафиксирован долгосрочным контрактом, решение — кандидат на упрощение, а не на слепое воспроизведение.

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

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

Совместимость с итеративными процессами. Цикл RDD естественно встраивается в спринты и спирали (см. спиральная модель, RAD), не требуя «фазы большой архитектуры» upfront. Архитектура поставляется инкрементами вместе с функциональностью. Пример: в Scrum-команде виток RDD естественно совмещается со спринтом: риски пополняются на refinement’е, снятие демонстрируется на review, переоценка происходит на retrospective.

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

Недостатки и риски

Субъективность оценки рисков. И вероятности, и последствия оцениваются экспертно, а эксперты ошибаются и оптимистичны. Реестр, в котором топ-позиции заняты не теми угрозами, направляет архитектуру мимо цели — со всеми затратами и без защитного эффекта. Средства частично известны: опора на данные (метрики, инциденты, история аналогов), регулярная переоценка, привлечение нескольких оценщиков — но радикального решения нет, и это принципиальное ограничение подхода. Почему это принципиально: в самом RDD нет внутреннего механизма самокоррекции оценок — таким механизмом становится только регулярная переоценка по фактам. Типичный сценарий: интеграционные риски систематически занижаются, потому что «провайдер серьёзный», и топ витка занимает угроза с приятной оценкой вместо неприятной.

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

Может недооценить архитектурную гигиену. В буквальном прочтении «нет риска — нет усилий» RDD оправдывает отказ от дешёвых, но систематически полезных практик: осмысленных имён, аккуратных границ модулей, базовой слоистости. Их ценность не привязана к конкретному риску, они снижают все будущие изменения сразу. Зрелое применение RDD учитывает это через риски эволюционности; незрелое — использует подход как алиби для небрежности. Почему это болит: ценность гигиены размазана по всем будущим изменениям и потому не «продаётся» ни одному конкретному риску. Пример: команда отменила единые правила границ модулей («риска нет») — и через полгода каждый новичок тратит недели на расшифровку структуры; в реестре это никак не отражено.

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

Дополнительный процессный вес. Реестр нужно вести, пересматривать, синхронизировать с ADR и планом. Для небольшой команды и короткого проекта это накладные расходы, сопоставимые с выгодой, — граница применимости, за которой RDD не окупается (см. «Когда НЕ использовать»). Ориентир здравого смысла: если ведение реестра стоит больше одного-двух часов в неделю на команду, а проект короче месяца, накладные расходы уже сопоставимы с любой мыслимой пользой.

Соблазн псевдоточной оценки. Численные оценки «вероятность 0.3 × ущерб 5 млн» создают иллюзию точности, которой в основе нет. Полезно упорядочение, а не числа; команды, играющие в цифры, тратят усилия на квантификацию вместо анализа существа угроз. Пример: часовой спор о том, 0.3 или 0.4 вероятность сбоя брокера, не меняет ни решения, ни техники — полезный сигнал, что команда квантифицирует вместо анализа.

Когда использовать

  • Проекты с выраженными техническими рисками. Высокие пиковые нагрузки, жёсткие требования к доступности и безопасности, критичные интеграции с внешними системами, работа с новыми технологическими стеками — там, где цена архитектурной неудачи измерима и велика, риск-цикл даёт максимальную отдачу.
  • Новые и неизвестные домены. Когда команда плохо представляет предметную область, неопределённость сама порождает риски (неверная модель, неверные приоритеты интеграции). RDD заставляет вытащить эту неопределённость в явный реестр и атаковать её проектированием и прототипами до того, как на неё настроен код.
  • Ранние стадии с высокой неопределённостью. Предпроектная фаза, MVP с прицелом на рост, исследовательские разработки. Здесь RDD отвечает на главный вопрос стартапа — «где мы можем дорого ошибиться» — и предотвращает обе крайности: недопроектированное ядро, которое придётся переписывать, и преждевременную «архитектуру на вырост».
  • Итеративные процессы без фазы большого проектирования. Спринты, спирали, RAD — везде, где архитектура должна поставляться инкрементами, риск-цикл даёт дисциплинированный способ решать, какой инкремент архитектуры нужен следующим.
  • Распределённые и выросшие команды. Явный реестр и ADR-с-риском переносят архитектурные решения из личного знания в общие артефакты — это снижает потери при онбординге и географическом разнесении.
  • Регулируемые и аудируемые домены. Связка «риск → решение → проверка», зафиксированная в реестре и ADR, — готовый след для аудитов и сертификаций, где требуется обосновывать проектные решения.

Быстрая проверка по маркерам: чем больше пунктов ниже описывает ваш проект, тем выше ожидаемая отдача от RDD.

  • В требованиях встречаются числа и обещания: «99,9% доступности», «1000 RPS в пик», «PCI DSS», «интеграция с N внешними системами», «горизонт поддержки — пять лет».
  • Команда подолгу спорит о структуре («микросервисы или монолит», «нужен ли CQRS»), и спор не разрешается данными — только мнениями.
  • Для команды нов домен, стек или класс системы; неясно, где именно «можно дорого ошибиться».
  • Цена отказа внешне наблюдаема: деньги, здоровье, персональные данные, регуляторные санкции.
  • Проект ранней стадии с прицелом на рост: MVP, который через год должен выдержать на порядки большую нагрузку и функциональность.
  • В команде есть кому вести реестр: архитектор или техлид и хотя бы пара сеньоров, способных взвешивать угрозы.
  • Уже принята дисциплина ADR — RDD усилит её полем «снимаемый риск».
  • Система живёт в окружении внешних зависимостей (провайдеры, регуляторы, партнёрские интеграции), где состав угроз меняется вместе с внешней средой — реестр даёт механизм регулярной сверки с реальностью.

Когда НЕ использовать

  • Хорошо понятные рутинные проекты. Типовое CRUD-приложение на знакомом стеке, сайт-визитка, внутренний инструмент с десятком пользователей: риски известны и тривиальны, архитектура — шаблонная. Формальный риск-цикл здесь добавит процессного веса без пропорциональной пользы; достаточно шаблонных решений и здравого смысла.
  • Маленькие задачи с тривиальной архитектурой. Отдельная фича в устоявшейся системе, скрипт, интеграция в пару сотен строк: стоимость ведения реестра превысит стоимость самой ошибки. Дешевле сделать аккуратно и переделать при необходимости.
  • Жёсткий дедлайн без резерва на проектирование. В режиме паники риск-цикл вырождается в формальность (реестр не ведётся, решения не проверяются) — остаётся только словарь. Это симптом нездорового процесса; честнее признать, что проект работает без архитектурной дисциплины, и не имитировать RDD.
  • Команды без опытного архитектурного ядра. Если некому взвешивать риски и выбирать техники, внедрение RDD даст ритуальный реестр и ложное чувство управляемости. Сначала — рост экспертизы (наём или развитие), затем — подход.

Обратный набор маркеров — чем больше совпадений, тем вероятнее, что RDD не окупится и выродится в ритуал:

  • Горизонт проекта — недели: презентационный сайт к конференции, одноразовая кампания, прототип для внутренней демонстрации.
  • Стек, домен и класс системы типовые: CRUD-приложение, сайт на знакомой CMS, внутренний инструмент для десятка пользователей.
  • Стоимость возможной ошибки ниже стоимости процесса: переделать модуль дешевле, чем провести по нему риск-сессию и месяц вести записи.
  • В команде нет никого, кто лично видел последствия архитектурных ошибок, — реестр заполнится шаблонными формулировками из интернета.
  • Процессом управляет паника дедлайна: «проектирование» уже сокращено в расписании до нуля, и любое обсуждение рисков будет имитацией.
  • Проект уже прошёл фазу неопределённости, архитектура устоялась, а изменения носят локальный характер — реестру нечего приоритизировать.

Связанные подходы

RDD — один из материалов серии о driven-подходах; за разными аббревиатурами стоят разные «движущие силы» (риски, тесты, поведение, домен и т. д.). Ниже — карта родственных подходов со ссылками на опубликованные статьи базы знаний.

Подход Движущая сила Что управляет дизайном Уровень применения
RDD Риски Реестр рисков и приоритеты Архитектура и проект
TDD Тесты Исполняемая спецификация (Red-Green-Refactor) Код и команда
Type-TDD Типы Система типов как пруфер Код и архитектура
BDD Поведение Сценарии Given-When-Then Команда и заказчик
FDD Фича Процесс доставки фич Команда и организация
MDD Модель Формальная модель как источник кода Код и инструментальные цепочки
  • TDD — Test Driven Development — движущая сила — тесты как исполняемая спецификация. TDD и RDD дополняют друг друга: RDD решает, где и сколько проектировать, TDD страхует поведение спроектированного кода коротким циклом. Оба подхода разделяют идею малого проверяемого шага.
  • DDD — Domain Driven Design — движущая сила — домен. Частный, но мощный случай сочетания: риск «неверная доменная модель» закрывается техниками стратегического DDD (bounded contexts, единый язык); RDD подсказывает, когда эти техники оправданы, а когда это перестраховка.
  • BDD — Behaviour Driven Development — поведение на уровне требований. Живёт выше уровня архитектуры и не конкурирует с RDD; риск «неправильно поняли требования» закрывается BDD-практиками.
  • FDD — Feature Driven Development — фича как единица организации работы. Ортогонален RDD: FDD управляет процессом доставки, RDD — глубиной проектирования внутри этой доставки.
  • MDD — Model Driven Development — формальная модель как источник истины. Контраст поучителен: MDD движется к полноте модели, RDD — к минимальной достаточности; RDD фактически отвечает на вопрос «сколько MDD-моделирования нужно».
  • ATDD — Acceptance Test Driven Development — критерии приёмки на уровне требований; работает выше архитектуры и совместим с RDD.
  • HDD — Hypothesis Driven Development — гипотеза как движущая сила продуктового развития. Ближайший родственник по духу: и риск, и гипотеза — формы явной неопределённости; HDD проверяет продуктовые гипотезы экспериментами, RDD снимает технические риски проектированием и проверкой.
  • Type-TDD — Type Driven Development — типы как средство верификации инвариантов. Пример техники, которую RDD может назначить на риск эволюционности: строгая система типов снижает пространство некорректных изменений.
  • Спиральная модель — исторический первоисточник идеи риск-управляемых итераций (Боэм); RDD переносит её логику с процесса на архитектуру.
  • RAD — Rapid Application Development — итеративная быстрая разработка; RDD отвечает на вопрос «чем пожертвовать из проектирования», не давая скорости выродиться в under-engineering.
  • Эволюционная архитектура — архитектура как непрерывно поддерживаемое свойство; RDD поставляет ей механизм приоритизации: какие фитнес-функции и границы строить следующими.
  • ADR — фиксация архитектурных решений; в RDD каждое решение обязано ссылкой на снимаемый риск.
  • Проектирование систем — RDD как дисциплина выбора глубины проектирования внутри общей практики system design.
  • SDLC — место риск-цикла в жизненном цикле: прежде всего фазы анализа и проектирования, итеративно повторяемые.

Удобный способ читать всю серию — сравнивать движущие силы. Тесты (TDD), типы (Type-TDD) и модели (MDD) — артефакты-верификаторы: они проверяют уже принятое решение и страхуют его исполнение. Домен (DDD) и поведение (BDD) — источники содержания: они говорят, что именно строить и каким языком это описывать. Фича (FDD) и гипотеза (HDD) — единицы ценности и неопределённости: они управляют порядком работы и её обоснованием. Риск занимает в этом ряду особое место: он единственный из перечисленных измеряет цену ошибки, а не форму правильного решения. Отсюда роль RDD в портфеле практик: он не конкурирует ни с одним подходом, а отвечает на мета-вопрос — какие из них, где и в какой дозе окупаются. Риск «поведение специфицировано неточно» закрывается практиками BDD; риск «доменная модель неверна» — стратегическим DDD; риск «рефакторинг небезопасен» — TDD; риск «продукт строится на неверном предположении» — HDD; риск «все перечисленные сразу» не закрывается ничем — он снимается приоритизацией самого реестра.

Тёзка по аббревиатуре — Readme Driven Development (движущая сила — документация: README до кода) — упоминается здесь текстом, без ссылки: статья этой серии ещё не опубликована и готовится. «Сатирические» варианты вроде Panic Driven Development рассматриваются в отдельных материалах серии.

Краткий вердикт для руководителя

RDD — это инвестиция в управляемость архитектурных усилий: вместо «проектируем сколько привыкли» — «проектируем ровно под дорогие способы неудачи». Эффект: концентрация на критичном, отсутствие over-engineering, обоснованные и проверяемые архитектурные решения, раннее снятие самых дорогих рисков. Цена: ведение реестра, зависимость от качества экспертизы (субъективность оценок), риск не заметить системные угрозы и потребность в зрелой команде. Берите, если проект технически рискован (нагрузка, доступность, безопасность, интеграции, новый домен), находится на ранней стадии с высокой неопределённостью или команда давно спорит о том, «сколько архитектуры нужно». Не берите, если проект рутинный и понятный, задачи мелкие, дедлайн не оставляет резерва или в команде нет архитектурного ядра, способного взвешивать риски. Главный практический минимум, который стоит забрать даже без полного внедрения, — привычка отвечать на вопрос «какой риск закрывает эта архитектура?» до того, как платить за неё временем команды.

Источники и материалы

Первоисточники и ключевые публикации

  • George Fairbanks. Just Enough Software Architecture: A Risk-Driven Approach. Online Associate O2S, 2010 — фундаментальный первоисточник: формулировка вопроса «сколько архитектуры достаточно», риск-цикл и каталог техник.
  • Barry Boehm. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT / IEEE Computer, 1986 — спиральная модель; историческая основа риск-управляемых итераций, на которую опирается RDD.
  • Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice. Addison-Wesley (3-е изд. — 2012, рус. пер. «Архитектура программного обеспечения на практике») — канонический учебник архитектуры; атрибуты качества и связь «качество → архитектурные решения», в том числе риск-ориентированный выбор тактик (ADD-метод).
  • ISO/IEC/IEEE 42010 — практика описания архитектуры через точки зрения и опасения (concerns); формальный каркас, в который ложится риск-ориентированное проектирование.
  • PMBoK (Project Management Body of Knowledge), PMI — процесс риск-менеджмента проекта (идентификация, анализ, планирование ответов, мониторинг), с которым стыкуется технический реестр RDD.
  • SEI, Carnegie Mellon. Attribute-Driven Design (ADD) — метод проектирования по атрибутам качества; родственный RDD способ выводить архитектуру из приоритизированных требований-угроз.

Связанные материалы базы знаний