# Domain Modeling

> Строй и затачивай доменную модель проекта. Использовать, когда пользователь хочет зафиксировать терминологию или ubiquitous language, записать архитектурное решение, или когда другому скиллу нужно вести доменную модель.

- Skill: `serejaris/domain-modeling` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add serejaris/domain-modeling`
- Raw SKILL.md: https://api.skillmd.com/api/skills/serejaris/domain-modeling/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: serejaris (https://skillmd.com/u/serejaris)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/serejaris/domain-modeling

---


# Доменное моделирование

Активно строй и затачивай доменную модель проекта по ходу дизайна. Это *активная* дисциплина: оспаривать термины, придумывать сценарии на краях, записывать глоссарий и решения в тот момент, когда они кристаллизуются. (Просто *читать* `CONTEXT.md` за словарём это не этот скилл. Это однострочная привычка любого скилла. Этот скилл для случаев, когда ты меняешь модель, а не только потребляешь её.)

## Структура файлов

В большинстве репозиториев один контекст:

```
/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/
```

Если в корне есть `CONTEXT-MAP.md`, в репозитории несколько контекстов. Карта указывает, где живёт каждый:

```
/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← общесистемные решения
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← решения конкретного контекста
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/
```

Создавай файлы лениво: только когда есть что писать. Если `CONTEXT.md` нет, создай его, когда разрешён первый термин. Если нет `docs/adr/`, создай его, когда понадобится первый ADR.

## Во время сессии

### Сверяй с глоссарием

Когда пользователь использует термин, который конфликтует с языком в `CONTEXT.md`, скажи сразу. "В глоссарии 'cancellation' это X, а ты, кажется, имеешь в виду Y. Что из этого верно?"

### Затачивай размытый язык

Когда пользователь использует размытые или перегруженные термины, предложи точный канонический термин. "Ты говоришь 'account'. Ты имеешь в виду Customer или User? Это разные вещи."

### Разбирайте конкретные сценарии

Когда обсуждаются доменные отношения, прожаривай их конкретными сценариями. Придумывай сценарии, которые бьют по краям и заставляют точно провести границы между понятиями.

### Сверяй с кодом

Когда пользователь говорит, как что-то работает, проверь, согласен ли код. Если находишь противоречие, вынеси его: "Твой код отменяет Orders целиком, а ты только что сказал, что частичная отмена возможна. Что верно?"

### Обновляй CONTEXT.md сразу

Когда термин разрешён, обнови `CONTEXT.md` тут же. Не копи их пачкой. Фиксируй по мере появления. Формат: [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).

В `CONTEXT.md` не должно быть деталей реализации. Не считай `CONTEXT.md` спецификацией, черновиком или складом реализационных решений. Это глоссарий и больше ничего.

### Предлагай ADR редко

Предлагай создать ADR только когда верны все три пункта:

1. **Трудно откатить**: цена передумать позже ощутима
2. **Без контекста удивляет**: будущий читатель спросит "почему так сделали?"
3. **Результат настоящего компромисса**: были реальные альтернативы, и вы выбрали одну по конкретным причинам

Если любого из трёх нет, ADR не нужен. Формат: [ADR-FORMAT.md](./ADR-FORMAT.md).