ADR-001: Выбор модульного монолита

Статус: ✅ Accepted
Дата: 2026-06-11
Автор: openclaw-architect

Контекст

SprosOS Seed стартует с маленькой командой (1-3 разработчика) и одним клиентом (EcoYar). Нам нужно:

1. Быстро собрать работающий MVP (9 bounded contexts)
2. Обеспечить архитектурную чистоту и изоляцию модулей
3. Избежать операционной сложности микросервисов (оркестрация, деплой, observability)

Рассматривались два основных подхода:

• Микросервисы — каждый bounded context как отдельный сервис
• Модульный монолит — все BC в одном процессе, но с чёткими границами модулей

Решение

Выбираем модульный монолит.

Все 9 bounded contexts будут развёрнуты как единое приложение, но разделены на модули с явными границами:

• Каждый модуль — отдельная папка в apps/api/src/modules/
• Модули общаются через явные интерфейсы (не прямые вызовы)
• Данные каждого модуля — через его repository (изоляция доступа к БД)
• Модули могут обмениваться событиями через in-process event bus

Последствия

Положительные (+)

• Простота разработки: Один процесс, один деплой, одни тесты
• Быстрый старт: Не нужно настраивать межсервисное взаимодействие
• Простое тестирование: Интеграционные тесты без моков сетевых вызовов
• Единая БД: Нет проблем с распределёнными транзакциями на старте

Отрицательные (-)

• Риск нарушения границ: Без дисциплины модули "протекают" друг в друга
• Масштабирование: Нельзя масштабировать отдельные компоненты
• Привязка к стеку: Весь проект на Node.js/TypeScript

Стратегия смягчения

1. packages/domain/ — изолированная доменная логика без зависимостей
2. Каждый модуль имеет свой repository и schema
3. Code review проверяет границы модулей
4. При необходимости — рефакторинг в микросервисы по одному BC

Связанные документы

• PROJECT_CONSTITUTION.md (архитектура: modular monolith)
• ARCHITECTURE_PRINCIPLES.md (Domain-Core Separation, Open-Closed Contexts)
• BOUNDED_CONTEXTS.md