Признаки распределенного монолита ▪️Несколько сервисов почти всегда выпускаются одновременно ▪️Общая библиотека моделей (shared kernel) меняется вместе со всеми сервисами ▪️Сервисы читают или изменяют чужие таблицы ▪️Для теста одного сервиса требуется поднять другой сервис ▪️Один компонент невозможно запустить автономно ▪️Недоступность одного сервиса блокирует выполнение большинства операций ▪️Бизнес-операция требует согласованных изменений в нескольких БД ▪️Нельзя указать владельца данных и инвариантов ▪️Сервисы масштабируются только совместно Если большинство компонентов физически раздельны, но изменение, тестирование, развертывание и восстановление выполняются совместно – высокий шанс распределенного монолита (вероятность тем выше, чем больше положительных ответов). Важное замечание Распределенный монолит в отдельных случаях может быть подходящим решением, но это должно быть обоснованное решение с зафиксированным компромиссом. Например - изоляция доверенных зон, независимое масштабирование ресурса (отдельный процесс с тяжелым расчетом на GPU), нормативная граница и ряд других. То есть это исключение, для которого есть явное, проверяемое требование с фиксацией последствий.