ну я повторюсь - не от хорошей жизни в это лезут

ну есть еще вариант что "надо для рюземе и скучно"

я пока только таких видел)

"написал систему из трех микросервисов - микросервис апишки, микросервис базы данных и микросервис крона"

микросервис агрегирующий данные из всех других микросервисов не забывай

а да еще один критерий - если разработчики в душе не понимают что такое bounded context (или схожее понятие какое для вертикальных срезов) - будет пизда

Для таких хорошо подходит правило одной бд на сервис для допомоги с этими сложными концепциями, не исключает, но хелпует

а вынос supportive доменов и сервисов в отдельные сервисы, не трогая кор-домены и субдомены - это уже микросервисы или еще нет?

Можешь релизить эти штуки независимо - чё нет)

"маленькие штуки" проще тестировать только если нет зависимостей от других "маленьких штук". В остальном всё сложнее: компоновка, развертывание, координация. Примерно как генералам дать командовать ресурсами вместо армий отделениями по 10 человек.

зависимости от других штук - контрактное тестирование. И все становится изи. Не, если конечно зависимости настолько криво менеджатся что ты "хер знает кто как и с кем" то да, будут проблемки. Но это как бы больше про проектирование нормальное

что до "компановка развертывание etc" - на самом деле для каждого отдельного сервиса это все становится проще. Появляется сложность инфраструктуры между сервисами но большинство эту сложность тащит и так к себе за счет докеров куберов и т.д.

ну и опять же, если у тебя те масштабы на которых микросервисы один из возможных путей развития то стоимость этого всего может быть существенно ниже других "стоимостей".

В целом всегда предполагается что у тебя микросервисы это эволюция проекта а не с нуля. То есть ты уже должен подбираться к тем проблемам затраты на которые окупают все эти штуки. Это оч важно понимать что бы не попадать в ситуации в стиле "2 разработчика решили сделать 100 сервисов"

ну и опять же - serverless будет вынуждать тебя куда более строгие ограничения делать + куда больше стоимости поддержания инфраструктуры можно "скинуть на кого-то", например амазон или гугл клауд. В этом ключе вопрос только в умении разработчиков такие системы проектировать + характере проекта. Универсальных решений нет, надо понимать когда юзать

то есть проблема больше в том что люди и с монолитами проектировать не умеют, хотя казалось бы там должно быть проще

Да вообще люди часто херню в коде пишут )

ну и твоя аналогия не корректна. У тебя и так и так "генералы" будут командовать "отделениями". Просто появится необходимость в отдельном "отделении" которая будет заниматься платформой и помогать продуктовым "отделениям" не отвлекаться от фич.

как и продукты в сторях, как и клиенты в фича реквестах, мы все умные в ретроспективе

Я где-то слышал мысль что если вам нужны саги, то возможно вы что-то перемудрили в вашей системе и нужно еще раз подумать на самом деле ли они вам нужны

лучше уточнить когда саги нужны - когда есть колаборация и действия в рамках одного процесса который сага представляет выполняется несколькими экторами (собственно конкурентные запросы разруливать надо как-то). Как альтернатива распределенным блокировкам