Не всё обязано быть микросервисом

Какое-то время, пока я учил backend, микросервисы казались автоматически более правильной архитектурой. Отдельные сервисы, отдельные базы, Feign-клиенты, Docker-контейнеры — на схеме всё выглядит солиднее.

Потом, работая с реальными системами, я увидел другую сторону. Отдельный сервис — это ещё и отдельный деплой, сетевое взаимодействие, сценарии отказов, логирование и мониторинг.

Граница сервиса — вопрос не технический

Самый сложный вопрос не «сколько сервисов сделать». Он звучит иначе: «почему эти две части должны жить отдельно?»

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

Верно и обратное: когда граница найдена правильно, разделение себя оправдывает. Каждый сервис несёт свою ответственность и не обязан знать внутренности соседнего.

Как я подхожу к этому сейчас

Сначала разбираюсь в системе. Потом разделяю модули. И только после этого думаю, какую часть имеет смысл выносить в отдельный сервис.

Потому что хорошая архитектура — не та, где использовано больше всего технологий. А та, которой меньше всего больно, когда приходят изменения.