RMagistr2015Как правильно составлять карту модулей приложения?
Имхо, правильно её не составлять. Ибо это совершенно бессмысленное занятие - для мало-мальски большого приложения, как ни определяй правила построения этой "карты", получится неимоверных размеров необозримый граф, годный только висеть распечаткой во всю стену со словами "вот как у нас хреново охрененно".

RMagistr2015можно вообще запутаться в этих макаронных вызовах
А в "карте" запутаться ещё легче. Просто потому, что один модуль может вызывать другой из десяти различных мест в двадцати различных ситуациях - и на графе этого никак не отобразишь. А если начать укрупнять модули (естественное желание при их количестве, что бы ни называть модулем) всё это дополнительно слипается.

RMagistr2015хочется понять спросить узнать, есть ли какие-нибудь методики описания структуры связей модулей приложения? как-то отслеживать вложенность вызовов, документировать этот процесс в наиболее понятную форму? Придать этому многообразию структурированный вид?
Чтобы придать этому многообразию структурированный вид, нужно не отслеживать вызовы, а определить правила и добиться их соблюдения. Самое древнее и стандартное правило называется "чётко определить интерфейс каждого модуля, сделать его минимально возможным и не лазить в модуль мимо интерфейса".

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

da17,

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

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

dbpatchтак еще и порождается целый пласт новых проблем
Как и пласт новых возможностей.

dbpatchмониторить и деплоить монолитное приложение куда проще, чем следить за здоровьем тысяч микросервисов.
Если добавить в "деплоить" условие "без прерывания обслуживания" - ещё вопрос, назовём так.

dbpatchа какие ожидают прелести трассировки микросервисов (а поди собери трейс лог по десяткам нод в реалтайме) - это вообще неописуемо.
Прелести есть везде. Просто для примера - давайте просчитаем сценарий "одна из операций снабжена устойчивой утечкой памяти" для случая монолитного приложения и для случая микросервисов.