В чем разница обычного монолита и модульного монолита

Что проверяют

Понимаете ли вы, что модульный монолит отличается от обычного не способом деплоя, а границами внутри кода и данных. Следом обычно спрашивают, как эти границы удержать в .NET и как модуль потом вынести в отдельный сервис.

Как отвечать

Оба варианта это одно приложение и одна единица развёртывания. Разница в устройстве:

• обычный монолит: код разложен по техническим слоям на всё приложение (Controllers, Services, Repositories), любой класс может вызвать любой другой, один DbContext на все таблицы, JOIN между чужими доменами в порядке вещей. Со временем правка в заказах начинает ломать биллинг;
• модульный монолит: код нарезан по бизнес-возможностям (заказы, каталог, оплата). Каждый модуль владеет своими данными и открывает наружу только контракт.

Как это выглядит в .NET на практике:

• проекты на модуль: Orders.Core с реализацией и Orders.Contracts с публичными интерфейсами и DTO. Внутренние классы помечены internal, соседи ссылаются только на Contracts;
• данные: свой DbContext и своя схема в базе на модуль, без чтения чужих таблиц и без внешних ключей через границу;
• взаимодействие: синхронно через интерфейс контракта или внутрипроцессный медиатор, асинхронно через интеграционные события, для надёжности через outbox;
• контроль границ: архитектурные тесты на NetArchTest или ArchUnitNET, которые валят сборку, если Orders лезет во внутренности Billing.

Плюсы: простота деплоя и отладки монолита плюс управляемая связанность. Когда понадобится вынести модуль в сервис, вызов интерфейса заменяется на HTTP или брокер, а данные уже разделены.

Где спотыкаются

Называют модульным монолитом папки внутри одного проекта. Если всё public и один общий DbContext, границ нет, есть только сортировка файлов.

Обещают, что модули масштабируются независимо. Приложение масштабируется целиком, отдельно поднять только каталог нельзя.

Описывают модульный монолит как «микросервисы в одном процессе» и тащат туда распределённые практики: очереди и повторные попытки там, где хватило бы обычного вызова метода.