В таком случае это, скорее, не микросервисы, а "распределённый монолит".

спасают сервисы-перемычки, которые "замораживаю" формат на себе, и не дают измененным пакетам портить малину и создавать волну правок

Это же зависит от правок, можно так направить, что ни одна микросервисная архитектура не выдержит. И правка в одном месте это имхо миф, часто правишь на сервисе и как минимум на api gateway, и это если повезло и твоим сервисом никто не пользуется и апи можно поменять с поддержкой обратной совместимости.
Если конечно мы не считаем, что оборачиваем все фичи в feature toggles, то катить можно почти всегда не зависимо)

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

Я с этим согласен, я лишь к тому, что не всегда это возможно. Если не брать в расчёт искусственные методы создания независимости в виде тоглов.

"переложить бред сумашедшего в независимые правки" (с) интерпайз

бред - область ответствкенности бизнес-аналитика

...область ответственности отдела разработки :D Ну не будем о грусном

так что у нас не микросервисы еще?

хз как получить их в ваакуме

это просто хаус, просто похоронить сроки разработки. Учитывая как все быстро меняется если сделать систему A<>B<>C каждый с каждым

Тесты писать

Юниты

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

Быстро становится понятно, где там лишние связи

может интеграционые?

мы же все такие про внешние связи

ну там какой json приехал и прочее

Не-а

как нам помогут юниты отвечающие за сущности в коде?