Сообщить об ошибкеКороткий ответ
Разделять монолит стоит, когда отдельные команды блокируют друг друга при деплое, части системы требуют разного масштабирования или модуль стабильно слабо связан с остальным кодом; не стоит делать это, если домен ещё не устоялся, а команда маленькая и координирует изменения без трения.
Как это работает подробнее
Оценивают связанность (сколько вызовов/общих таблиц между предполагаемыми частями), частоту совместных деплоев и конфликтов в CI/CD, различия в требуемой нагрузке.
Пример кода
Схема
Сигнал "за": команда payments не может деплоить фичу, т.к. ждёт мерж в общий монолит от команды catalog.
Сигнал "против": домен "рекомендации" меняется каждую неделю, границы данных ещё не стабилизировались.Что использовать на практике
- Практика. Сигналы «за» — частые релизные конфликты между командами, разная требуемая доступность/SLA частей, разный профиль нагрузки; сигналы «против» — домен меняется еженедельно, небольшая команда без трения координации.
Подводные камни
- Риск. Разделять ради моды на микросервисы без измеримой проблемы; игнорировать стоимость разделения — рост операционной сложности должен окупаться реальной выгодой.