# 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.