Какой размер сервисов в строках кода, классах и папках

Что проверяют

Есть ли у вас инженерный критерий границы сервиса или только ощущение «большой или маленький». Цифры тут повод для разговора, а следом почти всегда спрашивают: когда вы последний раз делили сервис или, наоборот, склеивали два в один, и почему.

Как отвечать

Сразу скажите, что строки кода не критерий, а симптом. Размер сервиса определяют границы ответственности:

• граница по домену: один сервис владеет одним ограниченным контекстом (bounded context из DDD) и своими данными. Общая база на несколько сервисов означает, что граница проведена неправильно;
• владение командой: сервис целиком помещается в голову одной команды, и она выкатывает его без согласования с соседями;
• признаки перерастания: сборка и тесты идут десятки минут, в сервис коммитят несколько команд, релиз одной фичи ждёт чужую, у OrderService пять разных причин меняться;
• признаки дробления сверх меры: одна пользовательская операция превращается в цепочку синхронных вызовов, а любая доработка задевает три сервиса сразу. Это распределённый монолит.

Затем назовите свои реальные цифры как пример, а не норму: сколько тысяч строк и классов было в ваших сервисах на Spring Boot и какой из них считался слишком большим. Замерить быстро можно через cloc или SonarQube. Если у вас был монолит, так и скажите и расскажите, как в нём были разделены модули.

Про папки: в Java это пакеты. Расскажите, как делили: по слоям (controller, service, repository) или по фичам (order, payment), и почему при раскладке по фичам кусок проще вынести в отдельный сервис. Границы пакетов стоит закреплять тестами: ArchUnit ловит запрещённые зависимости, а Spring Modulith помогает держать модульный монолит, пока делить рано.

Где спотыкаются

Называют магическое число вроде «сервис не больше 500 строк». Это размер одного крупного класса, а не сервиса, и интервьюер сразу начнёт копать.

Путают размер класса и размер сервиса: рассказывают про разбиение длинных методов, хотя вопрос про границы развёртывания и владения данными.

Гордятся десятками крошечных сервисов и не видят цены: сетевые вызовы, распределённые транзакции, саги и трассировка вместо простого вызова метода.