Насколько вообще разумное решение запрещать сервисам любую синхронную комуникацию друг

с другом? У нас есть пачка сервисов, и когда сервису А требуются какие-то данные из сервиса B, то API gateway в рамках одного запроса либо забирает их из B и передаёт в A, либо сама бизнес логика переносится в гейтвей и он на основе данных из обоих сервисов решает что делать. Мне кажется это очень не удобно, но мне говорят, что это стандартная практика и сервисы вообще друг с другом по http не общаются.

Обычно ит депендс. Много синхрона действительно скорее плохо, т.к ведёт к потере автономности сервисов, может плохо влиять на отказоустойчивость и тд С другой стороны, иногда можно С третьей стороны, держать логику в гетвее это прям интересно. Если какой-то процесс вообще никак не выполнить без данных из другого сервиса, то нужно смотреть на процесс, данные, которые ему нужны и тд Возможно, проще просто асинхронно реплицировать данные из сервиса А в сервис Б и использовать именно эти локальные данные

через API сервиса пусть общаются друг с другом, зачем запрещать то? напрямую нельзя например в базу другого сервиса лазить, а через внешний API можно

Обычно это приводит к потере автономности, усложнению кодовой базы, влечёт за собой дальнейшее ошибочное доменное разделение и в итоге скатывается всё к распределенному монолиту с коллчейнами в 5-12 сервисов

Ну вообще то, что гейтвей сервису присылает нужные ему данные, как по мне, автономности не особо прибавляет, если сравнивать с синхроном. С другой стороны большинство таких кейсов у нас обычно связано с авторизацией, а ей, вроде как, место как раз в гейтвее. Просто очень топорно получается, типичный сценарий: У сущности есть определенный статус, в котором её редактировать могут только пользователи с определенным правом. Выходит на гейтвее мы сначала получаем сущность из сервиса А, смотрим на статус, если для него требуется право, идем в сервис прав Б и проверяем есть ли оно у него, иначе просто даем пользователю отредактировать её. Реплицировать всех пользователей с их правами не вариант. Переносить авторизацию в сервис А тоже как-то неправильно.

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

А почему бы права и роли не прокинуть в сам сервис ?

тут много вопросов короч которые влияют: 1. мы когда говорим о асинхронных взаимодействиях, мы говорим о том когда сервису А не важно когда сервис Б сделает операцию? или же просто то же что и с синхронным только не по http а через кафку условную? Что подразумеваем? 2. "авторизация" - не смешиваем ли мы понятие "авторизации" и "бизнес ограничений". Как проверить - если штука в определенном статусе - это влияет на "кто может делать" или "может ли делать вообще"? Вопрос локальности данных и того как эти ограничения с точки зрения temporal coupling и stale data зависят друг от друга. Может быть эти данные должны быть в одном сервисе. А быть может "статус" надо убрать и разделить сущность так что бы за разные этапы жизненного цикла отвечали свои сервисы 3. мы когда сервисы выделяем мы по сущностям это делаем или по bounded context? 4. мы в микросервисы вляпались потому что нужда заставила (автономность команд) или мы в игрушки поиграть решили (все и так поддерживает команда или две)

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

в целом "сервис" это некая штука которая обслуживает некие buisness capability и обычно строится вокруг bounded context, обслуживает некий под-процесс во флоу пользователя или некую бизнес логику. проверить качество границ можно расписав все зависимости всех сервисов друг от друга. Если на это предложение команда разработчиков скажет "ты че, там же пизда как сложно" значит границы кривые

1. Тут речь именно о синхронщине, потому-что нам не нужно никаких операций в Б проводить, нам нужно что-то сделать в А, основываясь на данных из Б, т.е получить их нужно вот прям щас. 3. Про bounded context тут вряд ли слышали, разделяем по сущностям в основном 4. Вообще чисто ради масштабируемости как я понял

1. распределенный стэйт это smell 3. вы сами себе роете могилу 4. почитайте ньюмана, вы сейчас скорее всего копаете могилу продукту

По 4 можно фулл название?