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

BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.
А кто мешает в одной СУБД иметь несколько разных бд, или в одной бд иметь разные схемы для каждого сервиса?

BE>Кто как делает?
Несколько лет тому назад делал проект для сети местных больничек.
Так, вот был реализованы следущие сервисы: "Расписание врачей", "Лаборатория", "Мед.Карта" и ряд вспомогательных сервисов.
Так же разрабатывал архитектуру сервисов для энерегетической западной компании.

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Я так не считаю.
А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?

Если у тебя есть необходимость в джойне данных между разными бд, то, скорее всего неправильно разбил доменные сущности.

В общем, микросервисы — это реально рабочий инструмент, но как и любым инструментом, им надо пользоваться правильно. Мало почитать книжки, надо сделать какой-нибудь свой пет проект с помощью микросервисной архитектуры.

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

BE>Несколько бд было только в том случае, если одна реляционная, а другая — нет.
А кто мешает в одной СУБД иметь несколько разных бд, или в одной бд иметь разные схемы для каждого сервиса?

BE>Кто как делает?
Несколько лет тому назад делал проект для сети местных больничек.
Так, вот был реализованы следущие сервисы: "Расписание врачей", "Лаборатория", "Мед.Карта" и ряд вспомогательных сервисов.
Так же разрабатывал архитектуру сервисов для энерегетической западной компании.

BE>Я тоже считаю, что плодить множество действительно микросервисов с кучей баз данных повышает трудоемкость разработки и поддержки проектов. В первую очередь — это необходимость согласовывать изменения между сервисами. И невозможность вытащить данные из одной бд sql запросом.
Я так не считаю.
А за чем тебе вытаскивать одним SQL запросом данные, которые в разных доменах?
Ну вот в моем примере,больному назначены те или иные анализы, в лаборатории своя предметная область, свои данные, на выход выдается стандартный отчет с целевыми показателями, выходят ли эти показатели за границу или нет.
За чем делать запрос в бд лаборатории и джойнить данные из таблиц лаборатории с данными из таблиц для мед.карты больного?

Если у тебя есть необходимость в джойне данных между разными бд, то, скорее всего неправильно разбил доменные сущности.

В общем, микросервисы — это реально рабочий инструмент, но как и любым инструментом, им надо пользоваться правильно. Мало почитать книжки, надо сделать какой-нибудь свой пет проект с помощью микросервисной архитектуры.

P.S. Пример с распиливанием сервиса Backlog — на 8 раздельных сервисов — это крайне тупая вещь, и через эту крайне тупую вещь, заставляют принять мысль, что вся идея микросервисов — тупая.