Границы сервисов
Самая сложная часть проектирования микросервисов — не технологии, а правильно провести границы: что входит в один сервис, а что в другой. Неправильные границы хуже, чем монолит — получаешь всю сложность распределённой системы, не получая выгод от независимости сервисов.
Главный ориентир — Domain-Driven Design (DDD) и понятие “ограниченный контекст” (bounded context). Сервис должен соответствовать законченной бизнес-возможности, а не техническому слою:
❌ Плохие границы (по техническому слою):
UserController-сервис, UserRepository-сервис, UserValidation-сервис
✅ Хорошие границы (по бизнес-возможности):
User-сервис (весь функционал работы с пользователями целиком)
Order-сервис (весь функционал заказов целиком)Копнуть глубже
Признаки правильной границы сервиса:
- Высокая связность внутри, слабая связанность снаружи (см. тему «GRASP») — сервис решает одну законченную бизнес-задачу;
- Своя база данных — сервис не лезет напрямую в чужую базу, общается только через API;
- Независимый деплой — можно выкатить изменения в одном сервисе, не трогая остальные;
- Команда владеет сервисом целиком — от кода до базы, без необходимости координироваться с другой командой на каждое изменение.
Признак неправильной границы — “болтливые” сервисы (chatty services). Если для выполнения одной пользовательской операции нужно сделать 10 синхронных вызовов между сервисами туда-обратно — это сигнал, что границы проведены неверно, либо логику стоило держать в одном сервисе, либо переключиться на асинхронное взаимодействие через события (см. тему «Событие vs команда»).
Распределённый монолит — антипаттерн, когда формально код разбит на сервисы, но они так тесно связаны (общая база, синхронные цепочки вызовов друг через друга), что деплоить и менять их по отдельности всё равно невозможно — получаешь всю боль распределённой системы без единой реальной выгоды.
• что такое "болтливые" сервисы и распределённый монолит (если дошёл до 2-го слоя).