Ваша система начинает тонуть в хаосе обработки бизнес-процессов, хотя каждый сервис работает отлично "как часы".
Простые цепочки вызовов и реакций на события, обработка компенсаций превращается в запутанную, хрупкую и не поддающуюся тестированию архитектуру.
Когда наступает тот момент, та точка поворота, в которой мы понимаем, что хореографии уже недостаточно и надо переходить к оркестрации и внедрению менеджера процессов?
Давайте попытаемся разобраться на что следует обратить внимание, чтобы понять, что уже пора внедрять централизованное управление.
Бизнес-процессы стали нелинейными и долгоживущими
Если в процессе развития вашей системы появляются следующие симптомы:
▸ Бизнес-процесс занимает минуты, а иногда даже и часы.
▸ Требуется ручное подтверждение некоторых шагов процесса.
▸ Нужны таймауты и паузы и повторное воспроизведение шагов спустя некоторое время.
▸ Требуется ожидание внешней системы.
▸ В процессах появились условия, которые запускают альтернативные цепочки участников.
Это значит, что без явного управления состоянием бизнес-процесса уже не обойтись, иначе система скатится в хаос. Участники процесса не должны "помнить, что было вчера" и реализовывать логику отложенного реагирования на события. Этим должен заниматься координатор процесса.
Компенсации и откаты стали хаотичными или неполными
В процессе развития и поддержки системы вы замечаете, что:
▸ Компенсации становятся не согласованными.
▸ Компенсации не всегда срабатывают и сильно зависят от шага, на котором остановился процесс.
▸ Нет гарантии, что все шаги откатятся в правильном порядке.
▸ Периодически возникают "зависшие" процессы, которые невозможно исправить без ручного вмешательства.
Это значит, что в системе пропала отслеживаемость (Observability). И подход с использованием хореографии уже явно недостаточен.
Количество сервисов, участвующих в бизнес-процессе стало больше 5-7
Если в одном бизнес-процессе начинают участвовать больше 5 - 7 компонентов. А мы помним про магическое число Миллера - у мозга есть встроенный лимит - одновременно держать во внимании 7 ± 2 объекта.
В результате даже опытным разработчикам, которые находятся долгое время в проекте необходимо время, чтобы понять цепочки вызовов, что уж говорить о новичках. Конечно в этом случае помогает документация, но как правило она ведется с опозданием, либо застывает на каком-то этапе.
Косвенные признаки
В дополнение к предыдущим пунктам, есть еще множество косвенных признаков, указывающих, что нужно переходить к оркестрации:
▸ Откаты и компенсации делаются «на коленке»: некоторые откаты требуют постоянного ручного вмешательства - запуск SQL-скриптов, просите поддержку вручную отменить заказ (нет согласованности данных).
▸ Процессы «зависают» без видимой причины: никто сразу не может сказать где завис бизнес-процесс, приходится вручную проверять логи и таблицы по нескольким компонентам.
▸ Расследование инцидентов превращается в детектив - приходится действовать как Шерлок Холмс, чтобы найти причины.
▸ Команда боится реализовывать новые или изменять старые бизнес-процессы: а time-to-market новой фукнциональности значительно увелиивается.
▸ Невозможность контролировать время (Таймауты и SLA): многие бизнес-процессы являются долгоживущими и требуют ожидания внешних событий.
Нужно ли сразу переписывать все на "тяжелый" оркестратор
Нужно ли сразу переходить на коробочное решение и использовать Camunda/Temporal?
Все зависит от процессов в вашей организации и готовности инфраструктуры.
Стоит сразу переходить на Camunda/Temporal, когда:
✔ В вашей организации уже используется Camunda/Temporal.
✔ Инфраструктура готова к быстрому внедрению нового процесса.
✔ У вас есть достаточно времени на эксперименты и отладку.
✔ Бизнес-процесс настолько сложный и ветвистый, что простыми средствами уже не обойдетесь.
В остальных случаях стоит действовать эволюционно (итеративно):
✔ Выделите ключевые долгоживущие процессы (оформление заказа, верификация, возврат).
✔ Смоделируйте их как конечные автоматы — даже на бумаге.
✔ Реализуйте Process Manager как отдельный сервис (или часть домена), который:
- хранит состояние процесса,
- реагирует на события,
- инициирует команды,
- поддерживает таймауты и повторы.
✔ Если Process Manager уже не хватает настройте оркестратор и передайте ему управление вместо Process Manager.
Итеративный подход позволит вам сразу улучшить ситуацию в системе. И даст вам время на развертывание, тестирование и отладку оркестратора. Возможно, что переход от Process Manager к оркестратору будет практически бесшовным.
У кого был переезд с хореографии на оркестрацию, поделитесь кейсами?
Мой канал в telegram
#systemdesign #saga #processes #designpatterns #ProcessManager #microservices