domain-modelling

Files (1)

• SKILL.md

SKILL.md (first lines)

# Domain Modelling

Активно строй и уточняй доменную модель проекта в процессе проектирования. Это **активная** дисциплина — оспаривай термины, придумывай сценарии для граничных случаев, записывай глоссарий и решения в момент, когда они кристаллизуются.

(Просто *читать* `.docs/knowledge/domain-entities.md` для словаря — это не этот скилл. Этот скилл применяется, когда модель *меняется*, а не просто потребляется.)

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

В этом проекте единственный контекст:

```
/
├── .docs/
│   ├── knowledge/
│   │   ├── README.md            ← индекс базы знаний
│   │   ├── domain-entities.md  ← глоссарий доменных сущностей
│   │   └── ...
│   └── adr/
│       ├── YYYY-MM-DD_название.md
│       └── outdated/
└── ...
```

Создавай файлы лениво — только когда есть что записать. Если `.docs/knowledge/domain-entities.md` не существует — создай его при первом зафиксированном термине. Если `.docs/adr/` не существует — создай при первом ADR.

## В ходе сессии

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

Когда пользователь использует термин, противоречащий уже существующему языку в `.docs/knowledge/domain-entities.md`, немедленно укажи на это:
«В глоссарии "отмена" определена как X, но похоже ты имеешь в виду Y — что из этого верно?»

### Уточняй размытый язык

Когда пользователь использует расплывчатые или перегруженные термины, предложи точный канонический термин:
«Ты говоришь "аккаунт" — ты имеешь в виду Клиента или Пользователя? Это разные сущности.»

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

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

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

Когда пользователь утверждает, как что-то работает, проверяй, согласен ли с этим код. Если находишь противоречие — выноси на поверхность:
«В коде отменяется весь Заказ целиком, но ты только что сказал, что частичная отмена возможна — что из этого верно?»

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

Когда термин зафиксирован — сразу обновляй `.docs/knowledge/domain-entities.md`. Не откладывай. Файл должен быть полностью свободен от деталей реализации. Не используй его как спецификацию, черновик или хранилище технических решений. Это глоссарий и только глоссарий.

Не забудь обновить `.docs/knowledge/README.md`, если добавляешь новые файлы в базу знаний.

### ADR — только по делу

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

1. **Сложно откатить** — цена изменения решения позже ощутима
2. **Удивляет без контекста** — будущий читатель задастся вопросом «почему так сделано?»
3. **Результат реального выбора** — были настоящие альтернативы, и одна выбрана по конкретным причинам

Если хотя бы одно условие не выполнено — ADR не нужен.

Файл ADR называй по формату: `.docs/adr/YYYY-MM-DD_краткое-название.md`. Готовые ADR не изменяются — только создаются новые или устаревшие переносятся в `.docs/adr/outdated/`.

From YamiHilik/SDLCRoom, Apache-2.0.

More from YamiHilik/SDLCRoom