Scenario Slicing: Как перестать проектировать «галлюцинации»

Один «целевой сценарий» в ТЗ — это почти всегда фантазия, а не описание реальности. В жизни системы не идут по прямой, они ветвятся.

Чтобы не строить архитектуру на надежде, используйте Scenario Slicing — проектирование минимум трех состояний реальности:

🟢 1. «Всё пошло хорошо» (Happy Path)
Контекст: Интеграции отвечают мгновенно, данные валидны, пользователь действует по инструкции.

Суть: База, на которой строится MVP.

🔴 2. «Всё пошло плохо» (Worst Case)
Контекст: Таймауты, дубли запросов, частичные отказы сервисов.

Суть: Здесь проектируются транзакции, компенсации и адекватные тексты ошибок.

🟡 3. «Как обычно» (Reality Check)
Контекст: Где-то отвалилось, где-то подставили заглушку, кто-то довносит данные руками через админку.

Суть: Описание того, как система выживает в «грязной» среде.

Зачем это аналитику? Когда вы прогоняете требование через эти три фильтра, вскрывается «цена устойчивости»:

Детектор ставок: Вы сразу видите, где решение — это решение, а где — просто ставка (авось не упадет).

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

Управление ожиданиями: Вы фиксируете не «система должна», а «мы осознанно принимаем риск, что здесь пользователь застрянет».
Как применить это сегодня: Возьмите любое критичное требование из вашего проекта и ответьте на 3 вопроса:
Как это работает, если API соседа лежит 30 секунд?
Что видит пользователь, если он нажал «Оплатить» дважды?
Кто и как узнает, что данные не синхронизировались?

Итог: Scenario slicing не делает систему неубиваемой. Он делает прозрачной цену её выживания.