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