Недавно столкнулся с ситуацией, что один легаси-процесс содержал основную логику в скрипте на 10-15 экранов, что сделало дебаг довольно долгим и грустным.

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

В итоге здесь видятся 2 варианта, но каждый со своими особенностями:

1. Отрефакторить в полноценный метод в сервисе. Тут сразу вопрос - куда? Если вы, например, популярно разбиваете микросервисы по доменам, то придется или мешать несколько моделей данных/доменов в один сервис чисто ради этой операции, или создавать под такое отдельный сервис. В долгосрочной перспективе первый вариант избавит вас от всякого разделения по доменам, а второй грозит раздуванием количества сервисов чисто ради утилитарных функций.. или созданием вспомогательных сервисов, на которые будет завязано все остальное.

2. Декомпозировать скрипт в самом процессе оркестратора.

Может сработать, но с оговорками. Логика процесса в оркестраторе - это не полноценный бэкенд на вашем любимом {languageName}, и разнесенный на несколько этапов скрипт может не очень сильно выиграть в читаемости или удобстве работы, если преимущество вообще будет.

❓  Стало интересно, кто сталкивался с похожим усложнением и как решали?