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