Какие рекомендации и практики для определения границ микросервисов и разделения функциональности существуют

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

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

Как отвечать

Опорный подход здесь DDD:

• поддомены: сначала карта бизнес-возможностей, затем деление на ключевые, поддерживающие и типовые. Ключевые разрабатывают сами, типовые часто покупают;
• ограниченный контекст: область, где термин значит одно и то же. «Заказ» у продаж, склада и доставки это разные модели с разными атрибутами, и это нормально. Кандидат в сервис это контекст, а не сущность;
• Event Storming: воркшоп с бизнесом, где на стикерах выкладывают доменные события в прошедшем времени («Заказ оплачен»), команды и агрегаты. Скопления событий вокруг одного агрегата и смена словаря подсказывают границы;
• агрегат как граница транзакции: то, что должно меняться атомарно, живёт в одном сервисе. Если два сервиса постоянно приходится менять в одной транзакции, граница проведена неверно;
• своя база у сервиса: чужие данные только через API или события, без общих таблиц;
• связи между контекстами: карта контекстов с паттернами Customer/Supplier, Anti-Corruption Layer, Published Language. Синхронный REST для запросов, события через брокер для уведомлений, сага для процессов через несколько сервисов;
• закон Конвея: сервис должен помещаться в зону ответственности одной команды.

Результат аналитик фиксирует в C4 на уровне контейнеров, в диаграммах последовательности для межсервисных сценариев и в контрактах OpenAPI и AsyncAPI.

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

Режут по сущностям: сервис пользователей, сервис товаров, сервис заказов как CRUD над таблицами. Любой сценарий тогда требует цепочки синхронных вызовов, и получается распределённый монолит.

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

Предлагают делить по технологиям: этот сервис на Java, этот на Node.js. Стек следует из границы, а не определяет её.