В этой статье
Проверьте границы на примере заказа
Представьте продукт с каталогом, заказами и счетами. Модульный монолит сохраняет одно развёртывание с явными интерфейсами модулей. Заказы не должны напрямую менять таблицы счетов только из-за общей БД. Полезная граница показывает бизнес-ответственность до превращения в сетевую.
Пройдите сценарий отмены заказа после выставления счёта. Кто разрешает отмену? Какие записи меняются вместе? Где компенсация? Если команда не отвечает внутри одного процесса, разделение на сервисы распределит неоднозначность. Spring Modulith помогает моделировать модули, но предметные решения остаются за командой.
Где проходит граница?
Оба подхода требуют понятной ответственности за бизнес-функции.
Модульный монолит
Модули в одном развёртывании. Границы соблюдаются внутри приложения.
Микросервисы
Независимые развёртывания. Границы проходят также через сеть, хранилища и эксплуатацию.
Начинайте с минимальной управляемой границы
Модульный монолит объединяет развёртывание, наблюдаемость и согласованность данных, сохраняя предметные границы в коде. Часто это безопаснее для одной команды и общего ритма выпусков.
Микросервисы полезны при реальных устойчивых требованиях независимой ответственности, масштабирования, доступности или выпуска. Раннее разделение лишь превращает кодовые границы в сетевые, информационные и инцидентные.
Проверяйте границы до распределения
Выделяйте модули по бизнес-возможностям, задавайте направление зависимостей и запрещайте доступ к чужим таблицам. Если модульность не выдерживает одного процесса, API и очереди не сделают её яснее.
Отслеживайте совместные изменения модулей, конкуренцию за ресурсы и различия требований надёжности. Это более веские сигналы для выделения, чем число классов или размер репозитория.
Выделяйте сервис с планом восстановления
До выделения назначьте владельца, определите полномочия над данными, поведение при сбоях, окно совместимости, телеметрию и откат. Двойная запись без сверки создаёт две конкурирующие истины.
Выделите одну обоснованную границу, измерьте устранение исходного ограничения и оставьте остальное простым. Распределённая архитектура — постоянное эксплуатационное обязательство, не разовый рефакторинг.
Что выделение добавляет обычному запросу
После выделения счетов заказ может быть принят, пока счёт задерживается. Интерфейс должен показывать промежуточное состояние. Повтор не должен выписать второй счёт, а старое событие — перезаписать новую отмену. Это поведение продукта в той же мере, что и инфраструктурные вопросы.
До выделения нарисуйте состояния и владельцев переходов. Где клиент видит ожидание, кто сверяет незавершённую работу и расследует зависшую запись? Если нужна транзакция «всё или ничего» для каждого изменения, пересмотрите границу. Тесно связанную работу разумнее держать вместе, пока бизнес не может принять и объяснить частичный прогресс.
Выделите одну возможность и измерьте результат
Убедительный кандидат испытывает конкретное давление: отдельный ритм выпуска, собственная команда или существенно иной профиль ресурсов. Сначала зафиксируйте базу. Перенесите один интерфейс и владение его данными, сохраните совместимость при выпуске и проверьте уменьшение исходной проблемы.
Оцените координацию выпусков, дежурства и время прослеживания запроса. Если каждое изменение всё ещё требует одновременного выпуска всех команд, вероятен распределённый монолит. Остановите выделение до понимания связности. Цель — соответствие границ работе, а не число сервисов или эффектная схема.
Источники и дополнительное чтение
Документация проверена .
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Микросервисы по умолчанию лучше масштабируются?+
Нет. Они допускают независимое масштабирование при подходящих границах и нагрузке, но добавляют затраты на сеть, согласованность, выпуск и инциденты.