А) Монолит - это не плохо, особенно когда он модульный. Плохо big ball of mud. Монолит обычно ассоциируют с big ball of mud (макароны), на практике это часто действительно так, но проблема не в монолите, можно избежать скатывания монолита к big ball of mud.
Б) Сервис должен принадлежать команде, но при этом ничто не мешает делать кросс-аудит и выполнять ротацию. Это снизит вероятность к скатыванию в big ball of mud

Ответ: варианты А и Б противоречат только в одном, во владении. Сервис должен принадлежать одной команде, но при этом полезно делать кросс-аудит и выполнять ротацию.

логично, спасибо

хочу лишь добавить что big ball of mud в микросервисах это на порядки страшнее чем в монолите

да

MSA повышает требования к качеству проектирвоания системы

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

Поколение микросервисов не застало SOA, поэтому знакомых слов из SOA мало. Но мы же понимаем, что общего много.

Рекомандую эту книгу, как наиболее приложимую: https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543

Книга есть на русском, но в переводе не читал, ничего не могу сказать про качество перевода.

Некоторые вещи спорные, и всё же, книга очень полезная с моей точки зрения. И ещё нужно освежить DDD, т.к. микросервисы стали ближе к бизнесу.

Если перестать связывать soa с soap, то какие остаются отличия soa vs msa?

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

Если владелец один, то появляются очереди на изменения сервиса. Нужно следить за такими очередями и при их возникновении переводить сервис в публичную зону (или разрешить форкать, смотря что за сервис).
Но аудит чужих сервисов нужен, да.

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

аудит нужен, но есть вопрос.
Понимет ли внешний аудитор целевой бизнес-процесс, сможет ли он корректно оценить логику сервиса,
или все ограничится просмотром “правильности” Java-кода? Что думаете?

Да иногда и не платформа, но очередь изменений на сервис тормозит много проектов. Пр общем владении с очередями легче.
Можно разрешить чужие пулреквесты

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

Думаю, что нужен процесс, а не отдельные события аудита (экзекуции)

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

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

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

Согласен, не всех можно так мотивировать. Но почти всегда находятся те, кто готов сменить домен и погрузиться в чужую кухню

Можно попробовать оценивать не сам сервис, а дизайн ревью на его изменения. Насколько они сложные

Вот это ключевая мысль. Нужно учиться делать именно дизайн-ревью. И в целом подниматься выше кода. Это же очень интересно, потому что включается творчество