Классический вопрос, вызывающий бурные дискуссии и резкое глобальное потепление зон пониже поясницы: какого размера должен быть микросервис?
Я видел предложения измерять «микро» строками кода, количеством файлов, классов и ещё не пойми чем. Но все количественные метрики ломаются: тысяча строк простой бизнес-логики и тысяча строк сложного инфраструктурного кода дают совершенно разную нагрузку на команду.
Качественные определения тоже не дают магического числа:
Микросервис — это сервис, который одна команда может переписать за спринт.
А команда — это сколько? А спринт — неделя или месяц?
Микросервис — это сервис, который может разрабатывать один человек.
А если не может, это уже не микросервис?
Микросервис должен помещаться в голове одного человека.
Это уже ближе к полезному ориентиру: определение говорит не о количестве файлов, а о сложности и понятности ответственности. Но и его недостаточно, чтобы провести границу сервиса.
Важен не размер, а граница ответственности
Мне полезнее смотреть на бизнес-функции и изменения, ради которых сервис существует. У него должна быть понятная ответственность, а изменения внутри неё не должны постоянно требовать синхронных правок в соседних сервисах.
Bounded context из DDD помогает искать такие границы, но не даёт формулы «один контекст — один микросервис». Контекст может остаться модулем внутри монолита, если отдельный деплой не приносит пользы. И наоборот, слишком широкий сервис можно разделить, если разные части меняются и масштабируются независимо.
Поэтому «микро» для меня — не про минимальный объём кода. Это про достаточно узкую и связную ответственность, которой команда может управлять независимо. Строк и классов в сервисе должно быть столько, сколько нужно для этой задачи.
При этом хороший размер не спасает от неверно выбранной архитектуры. Для нового продукта я обычно предпочитаю monolith-first подход, а к разделению перехожу, когда границы домена и цена независимых изменений стали понятнее. Подробнее о компромиссах микросервисной архитектуры я писал в обзорах книг Сэма Ньюмена «Создание микросервисов» и «От монолита к микросервисам».