В чьей зоне ответственности находится выделение нового микросервиса?

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

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

Как отвечать

Честный ответ: финальное решение за архитектором или техлидом вместе с командой, которая будет сервис разрабатывать и сопровождать. Вклад аналитика при этом весомый, и его стоит расписать:

• границы предметной области: выделить бизнес-возможность или ограниченный контекст (bounded context в терминах DDD), показать, какими сущностями он владеет единолично, а какие только читает;
• аргументы за выделение: другой профиль нагрузки, свой темп изменений, отдельная команда-владелец, требования к доступности или безопасности, отличные от остальной системы;
• интеграции: кто будет вызывать новый сервис, синхронно по REST или gRPC или асинхронно через события в брокере. Контракты в OpenAPI или AsyncAPI, диаграммы последовательностей;
• данные: какие таблицы переезжают, кто становится источником правды, как обеспечить согласованность между сервисами;
• нефункциональные требования: объёмы, время ответа, SLA, аудит.

Хорошо, если упомянете закон Конвея: границы сервисов обычно повторяют границы команд, поэтому вопрос не только технический, но и организационный. Приведите пример из своей практики: что выделяли, кто был инициатором, какую часть работы делали лично вы.

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

Отвечают «это решает архитектор, я не участвую». Для системного аналитика это звучит как отказ от половины работы.

Перечисляют всех подряд, от бизнес-аналитика до менеджера проекта, и заключают «ответственность общая». Интервьюер слышит, что ответственного нет.

Предлагают выделять сервис по техническому слою, например «сервис базы данных» или «сервис валидации». Такой сервис связан со всеми остальными, и вместо независимых частей получается распределённый монолит.