# Domain Modeling

> プロジェクトのドメインモデルを構築し、研ぎ澄ませる。コードベースの用語について議論するとき、CONTEXT.mdを書く・編集するとき、ADRを記録・編集するときに使う。

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

---


# ドメインモデリング

設計しながら、プロジェクトのドメインモデルを能動的に構築し、研ぎ澄ませる。これは*能動的な*規律である: 用語に異議を唱え、エッジケースのシナリオを考案し、それが結晶化した瞬間に用語集や決定事項を書き留める。（用語のために `CONTEXT.md` を単に*読む*だけならこのスキルではない。それはどのスキルでもできる1行の習慣にすぎない。このスキルはモデルを単に消費するのではなく、変更しているときのためのものである。）

## ファイル構成

ほとんどのリポジトリは単一のコンテキストを持つ:

```
/
├── 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が必要になった時点で作成する。

`docs/` にファイルを足したら（ADR がその例）、索引 `docs/README.md` にパスと一行説明で1行足す。`docs/README.md` が存在しなければそのとき作る。索引も遅延的に作るものであり、空の `docs/README.md` を先回りして置かない。

```
- `docs/adr/0001-event-sourced-orders.md` — 注文をイベントソーシングで持つ決定（採用）
```

## セッション中に行うこと

### 用語集に照らして異議を唱える

ユーザーが `CONTEXT.md` の既存の用語と矛盾する用語を使ったら、即座に指摘する。「あなたの用語集では『キャンセル』はXと定義されていますが、今のはYを意味しているように見えます。どちらですか？」

### 曖昧な言葉を研ぎ澄ませる

ユーザーが曖昧・多義的な用語を使ったら、正確な標準用語を提案する。「『アカウント』とおっしゃいましたが、Customerのことですか、それともUserのことですか？ それらは別物です。」

### 具体的なシナリオで議論する

ドメインの関係性が議論されているとき、具体的なシナリオでストレステストする。エッジケースを突くシナリオを考案し、概念間の境界についてユーザーに正確さを求める。

### コードと照合する

ユーザーが「これはこう動く」と述べたとき、コードがそれと一致しているか確認する。矛盾を見つけたら表面化させる。「あなたのコードはOrder全体をキャンセルしますが、今、部分キャンセルが可能だとおっしゃいました。どちらが正しいですか？」

### CONTEXT.mdをその場で更新する

用語が確定したら、その場で `CONTEXT.md` を更新する。まとめて後回しにしない。起きたその瞬間に捉える。書式は [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md) を使う。

`CONTEXT.md` には実装の詳細を一切含めないこと。`CONTEXT.md` をspecやスクラッチパッド、実装判断の置き場所として扱わない。これは用語集であり、それ以外の何物でもない。

### ADRの提案は控えめに

以下の3つすべてが真であるときのみ、ADRの作成を提案する:

1. **元に戻しにくい**: 後で考えを変えるコストが無視できない
2. **文脈なしでは意外**: 将来の読者が「なぜこうしたのか？」と疑問に思うだろう
3. **本物のトレードオフの結果**: 本当に別の選択肢があり、特定の理由でその1つを選んだ

3つのうち1つでも欠けていればADRは不要。書式は [ADR-FORMAT.md](./ADR-FORMAT.md) を使う。