Признаки распределенного монолита

▪️Несколько сервисов почти всегда выпускаются одновременно
▪️Общая библиотека моделей (shared kernel) меняется вместе со всеми сервисами
▪️Сервисы читают или изменяют чужие таблицы
▪️Для теста одного сервиса требуется поднять другой сервис
▪️Один компонент невозможно запустить автономно
▪️Недоступность одного сервиса блокирует выполнение большинства операций
▪️Бизнес-операция требует согласованных изменений в нескольких БД
▪️Нельзя указать владельца данных и инвариантов
▪️Сервисы масштабируются только совместно

Если большинство компонентов физически раздельны, но изменение, тестирование, развертывание и восстановление выполняются совместно – высокий шанс распределенного монолита (вероятность тем выше, чем больше положительных ответов).

Важное замечание
Распределенный монолит в отдельных случаях может быть подходящим решением, но это должно быть обоснованное решение с зафиксированным компромиссом. Например - изоляция доверенных зон, независимое масштабирование ресурса (отдельный процесс с тяжелым расчетом на GPU), нормативная граница и ряд других. То есть это исключение, для которого есть явное, проверяемое требование с фиксацией последствий.