2.7 KiB
ADR-0005: DDD-границы внутри модульного Typst-монолита
Дата: 2026-08-26 Статус: Принято
Контекст
Шаблон должен расширяться новыми видами документов, но обычное использование должно оставаться простым. Один монолитный show с ветвлением по типу документа быстро свяжет корпоративные данные, file paths, domain-правила и пагинацию. Полноценные микросервисы или отдельные пакеты для каждого bounded context, напротив, избыточны для локальной Typst-библиотеки.
Рассматриваемые варианты
- Одна функция с
if kind == ...— минимальный старт, но любое расширение меняет общее ядро и повышает риск регрессии. - Модульный монолит с DDD-границами и profile contract — изоляция без инфраструктурной сложности.
- Отдельный Typst package для каждого вида документа — сильная физическая изоляция, но дублирование foundation и сложное совместное версионирование.
Решение
Выбрали модульный монолит со слоями Domain → Application и адаптерами Infrastructure/Presentation. Domain не импортирует presentation или infrastructure. Новый вид документа добавляется новым DocumentProfile, а не новой веткой в document().
Разрешённое направление зависимостей:
Facade → Application → Domain
│ ▲
├→ Infrastructure
└→ Presentation → Shared Components
Presentation и Infrastructure могут создавать domain-значения или читать их, но не изменяют domain-инварианты.
Последствия
Становится проще: добавление договора или другого профиля, независимые fixtures и локализация show/state.
Становится сложнее: необходимо поддерживать явные contracts и проверять import graph.
Закрывает дверь на: доступ domain-модулей к JSON, image, page, context и глобальным renderer-state.