Друзья, мне кажется, здесь аудитория достаточно зрелая, чтобы обсудить этот вопрос на интересном мне уровне абстракции. Допустим, мы разрабатываем какую-то очень сложную, но достаточно естественно декомпозируемую систему. Например, банковское приложение крупного банка или агрегатор такси, что-то такое. На одном краю спектра находится монолит, когда код системы представляет собой чудовище, а чтобы ее зарелизить, нужно сначала заморозить на полгода и эти полгода тестировать. На другом краю спектра находится death by a thousand microservices, когда существенный процент кода и работы с ним это обслуживание, собственно, микросервисов, а не какие-то более содержательные манипуляции с данными, а существенный процент сложности системы находится уже даже не в коде, а в графе взаимодействия этих самых микросервисов (и хорошо еще, если этот граф вообще наблюдаемый как какая-то визуализируемая или текстовая сущность, а не существует только имплицитно).
Собственно, вопрос, где находится золотая середина. Мой вариант ответа -- хороший микросервис разрабатывает команда, в которой каждый знает каждого и каждый senior понимает, что происходит в любой части кода. При этом дробить сильнее уже вредно, т.е. правильный размер команды микросервиса это 5-7 человек (так что сервис даже не совсем "микро").
Но я знаю, что очень часто систему дробят гораздо мельче, вплоть до того, что один программист разрабатывает и поддерживает несколько "микросервисов". Например, вместо одного бэкенда профиля пользователя мы устраиваем микросервис, который занимается аватарками, отдельно микросервис, который занимается самоописанием пользователя и т.п. Мне такой способ организации кажется абсурдным. Я не видел внятного обоснования, зачем так делать (хотя знаю цинично-реалистичное: job security архитектора, если такая роль в проекте отдельно выделена). Это я чего-то не понимаю, или все-таки они?