Почему?

"вполне крутиться" это в текущем состоянии индустрии весьма растягиваемое понятие

Да нет никакой разницы между http get и прямым вызовом процедуры. Кроме того, что для http get нет ни нормальных инструментов проверок зависимостей, синтаксиса и т.п.
Удаленные процедуры - это такой сильно улучшенный http get.

Дъявол в деталях: самое сложное не в факте наличия dblink или http get, а в составе данных, которые там передаются.
Был у нас нехороший опыт "платной ссылки" в составе http запросов, который инициирован неявное поведение в нескольких сервисах.

Именно

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

"Инструменты проверки зависимостей" упомянутые всуе выше это вообще не проблема сама по себе. Если у вас проблема с (взаимо) зависимостями или сложностью графа, просто необходимо инвестирование в управление этим аспектом. А поможет вам сэкономить три цента бесплатный плагин индуса КариРамы (или компилятор там) или нет это дело десятое.

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

Да вот это именно что проблема - о чем тут все с опытом поддержки сильно сервисной архитектуры в один голос и говорят )
При том, что rest/rpc - это еще не самая большая беда. А вот событийная модель - это совсем тяжко (

Зато красиво жы

Всё не так. Модульные вообще не в ту степь. Интеграционные ближе, но вопрос вообще не в этом. Делаете те которые нужны - которые решают вашу проблему. Называете как захочется и пишете книжку.

Задача "метод никому не нужен" вообще цирк. Студенту поручите тему для диплома. Чтобы был реферат на дюжину подходов.

Дорого - да, это может быть дорого. На машине ездить дорого, пешком дешевле

думаю, что wardley maps пользуются нынче большой популярностью потому, что они тоже похожи на астрологические карты звездного неба. Очень эффективный инструмент пугать себя и других: нарисовать линии между точками, а потом искренне переживать, что Сатурн нынче находится в созведии кольцееда...

"хрупко" тесты действительно часто складываются, инвариант. А всё почему - потому что тестированием занимаются лучшие люди.

HTTP GET - безопасный метод, виноват разработчик сервера

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

Имхо.

Я бы предложил рассматривать архитектуру более-менее сложного продукта (мы недавно считали сервисы - получилось 540)  больше не с точки зрения инструментальных средств, а скорее с позиций:
1) декомпозиции прикладной задачи на сущности-действия
2) инженерии систем, как правильно разложить поведение по системам

когда система становится достаточно сложна, тривиальные методы не работают.
Это и проблема и возможность одновременно.
Я ожидаю прихода методик инженерии систем в ИТ в виде нового класса инструментов

Я вот потихоньку думаю, что для сложных систем задача уже не про "связность между постановкой и поведением", а про "как бы упросить систему вести себя близко к нужному". И "как понять, когда появляется что-то не нужное".
И тут, конечно, хочется каких-то инструментов управления взаимодействием, но пока удобных и эффективных решений я не видел (хотя регулярно пытаюсь что-то придумать, но оно работает для относительно небольших систем и относительно недолгое время). А вот про 100+ сервисов (не микро) и 10+ лет развития в сложной среде - это сложно (