Почему? И как это исправить?
Все знают: "Процесс должен быть сквозным — от заказа до доставки". Логично на бумаге. Но в реальности автоматизированные процессы превращаются в минное поле:
- Одна ошибка в оплате валит весь заказ
- Изменения требуют созвонов 5 команд
- Тесты длятся часы, баги не воспроизводятся
- Новички месяц изучают "большую схему"
Почему так происходит?
Чем больше элементов и связей в диаграмме, тем система становится более хрупкой. Малейшее изменение (новые регуляции, сбой сервиса) — и все рушится.
Но решение есть — теория остаточности
Если коротко, Теория остаточности — это идея
Барри О’Рейли
:🔹
Системы (ПО, процессы) выживают под стрессом, если состоят из малых остатков (Residues) — того, что остается рабочим после изменений/сбоев.🔹
Чем больше элементов (N) и связей (K) — тем система хрупче.🔹
Стабильность рождается в маленьких независимых блоках, готовых к хаосу реальности.
Как это использовать:
1. Разделите по доменам
Заказы — отдельный процесс. Оплата — отдельный. Доставка — отдельный. Изменения в одном месте не трогают другие.
2. Внутри каждого модуля — маленькие блоки
Используйте Call Activities. Каждый блок решает одну задачу, легко тестируется и меняется.
3. Домены говорят только событиями
"Оплата прошла" → запускается доставка. Без знания внутренних деталей друг о друге.
Результат:
- Стресс локальный, не по всей системе
- Команды работают автономно
- Тесты быстрые и надежные
- Процессы легко понимают новички
Это не про "разбить на кусочки", а про то, как сделать процессы устойчивыми к реальной жизни.
🔗 Полный перевод на Хабре 👉
https://habr.com/ru/articles/997096/