Модульный монолит
↑ 8.2 Архитектурные стили и DDD · ← Предыдущая · → Следующая
Зачем это на собесе
Часто правильный ответ на «микросервисы или монолит»: модульный монолит с границами, готовыми к выделению.
Объяснение
Один процесс и деплой, но код разделён на модули с чёткими границами, которые соответствуют bounded contexts.
| Свойство | Требование |
|---|---|
| Границы | модуль = отдельные проекты/сборки, публичный контракт (интерфейсы/события), всё остальное internal |
| Данные | у каждого модуля своя схема/таблицы; нет JOIN между модулями и общих таблиц |
| Взаимодействие | через публичные API модулей или доменные события (in-process bus) |
| Зависимости | без циклов; проверяются архитектурными тестами |
| Команды | модуль принадлежит команде |
| Эволюция | модуль можно вынести в сервис, заменив вызовы на сетевые |
src/
Modules/
Orders/ Orders.Contracts Orders.Core Orders.Infrastructure
Billing/ Billing.Contracts Billing.Core Billing.Infrastructure
Catalog/ ...
Host/ # композиция модулей, единый процессpublic interface IBillingModule { Task<InvoiceId> CreateInvoiceAsync(OrderId id, Money total, CancellationToken ct); } // публичный контракт
builder.Services.AddOrdersModule(cfg).AddBillingModule(cfg);Плюсы перед микросервисами: простота эксплуатации и транзакций, ниже задержка, легче рефакторинг. Плюсы перед «большим комом»: границы и независимость.
Нюансы и подводные камни
- Без дисциплины (общая БД, прямые ссылки на внутренние типы) модули сливаются обратно в ком.
- Общий код
Commonразрастается в новый монолит внутри монолита. - Транзакции между модулями появляются «случайно»: используйте события и eventual consistency, если планируете вынос.
- Один релиз для всех модулей: тесты и зависимость релизов.
Практика
- Разделите проект на 2–3 модуля с контрактами и
internalреализацией. - Добавьте архитектурный тест на запрет ссылок на внутренности модулей.
- Разведите схемы БД по модулям.
Вопросы с ответами
Зачем модульный монолит?
Даёт преимущества разделения по границам без сложности распределённой системы; путь к микросервисам при необходимости.
Как не допустить деградации в «ком»?
Публичные контракты,
internal, раздельные схемы данных и автоматические проверки зависимостей.