{{書名}} 比喩レジストリ
概要
本ファイルは全書で使用する比喩のマッピング関係を管理します。各コア技術概念に結びつけられる主比喩は 最大1つ とし、全書を通じて一貫性を保ちます。
比喩の品質基準
良い比喩は以下の条件を満たす必要があります：
- ✅ 正確性: 比喩の重要な特徴が技術概念の重要な特徴と一致している
- ✅ 親しみやすさ: 対象読者が比喩の本体を十分に知っている
- ✅ 拡張性: 概念の複数の側面に延伸でき、どこかの時点で「破綻」しない
- ✅ 明確性: 読者に誤った理解をさせない
比喩レジストリ
| 技術概念 | 結びつけられた比喩 | 初出箇所 | ステータス | 注意事項 |
|---|---|---|---|---|
| event loop | レストランのウェイター：一人のウェイター（シングルスレッド）が複数のテーブルの客（タスク）を順番にサービスし、料理が来るのを一つのテーブルで待ち続けず（ノンブロッキング）、次のテーブルをサービスしに行く | ch{{N}} | 活発 | 「複数のウェイター」のシナリオには延伸しないこと。それはマルチスレッドです。「一人の交互サービス」を強調し、「並列サービス」ではありません |
| middleware | ライン作業員：各作業員（ミドルウェア）がベルトコンベヤー上の製品（リクエスト）に一つの処理を行い、処理後に次の作業員に渡すか、不合格品をそのまま返送（リクエストの終了）することもできる | ch{{N}} | 活発 | 「順次実行」と「中断可能」の2つの特性を強調します。「作業員同士が直接会話できる」には延伸しないこと——ミドルウェア間は req/res を通じて通信し、直接通信はしません |
| closure | リュックサック：関数がそれを定義した教室（スコープ）を離れても、リュックサック（クロージャ）を持っていき、その中には教室の教科書（変数）が入っている | ch{{N}} | 活発 | 「持ち出す」と「まだアクセスできる」を強調します。「リュックの中身が変わる」とは言わないこと——技術的にはクロージャは外部変数を変更できますが、この延伸は初学者が混乱しやすい |
| {{技術概念}} | {{結びつけられた比喩}} | ch{{N}} | {{活発/廃止}} | {{注意事項}} |
廃止比喩の記録
| 技術概念 | 元の比喩 | 廃止理由 | 代替比喩 | 廃止日 |
|---|---|---|---|---|
| {{概念}} | {{元の比喩}} | {{廃止理由、例：「読者フィードバックで誤解を生じやすい」}} | {{新しい比喩（上記のレジストリにすでに登録されている必要があります）}} | {{YYYY-MM-DD}} |
衝突検出ルール
ルール1：一概念一比喩
同じ技術概念は全書を通じて 1つの主比喩 のみ使用します。
- ❌ 違反例：第3章で event loop を「交通警察」に例え、第7章で「ベルトコンベヤー」に例える
- ✅ 正しい方法：全書を通じて「レストランのウェイター」に統一し、異なる章でその比喩の異なる側面を延伸できる
ルール2：異なる概念は比喩を共有しない
2つの異なる技術概念に同じ比喩を使うと、読者が混乱します。
- ❌ 違反例：middleware に「ライン作業」、pipeline にも「ライン作業」を使う
- ✅ 正しい方法：関連するが異なる概念に対して、区別できる比喩を設計する
ルール3：比喩の延伸は一貫性を保つ
第3章で「middlewareはライン作業員のようだ」と述べた場合、後続の章でその比喩を延伸する（例：「ラインに品質検査員を追加した」）ことはできますが、矛盾させることはできません（例：「ライン作業員が複数の製品を同時に処理できる」——これは middlewareの逐次処理の特性と矛盾します）。
ルール4：新しい比喩は事前に登録する
新しい比喩は 本ファイルに事前に登録してから、本文で使用してください。登録時に確認すること：
- [ ] その概念にすでに結びつけられた比喩があるか？
- [ ] 新しい比喩は既存の比喩と衝突しないか？
- [ ] 新しい比喩は上記の「比喩の品質基準」を満たしているか？
ルール5：シンプルな概念に比喩は不要
すべての概念に比喩が必要なわけではありません。概念自体が直観的に分かる場合（例：「変数への代入」）、無理に比喩を使うと認知負荷が増えます。
章別インデックス
第{{N}}章: {{章タイトル}}
- {{技術概念A}} → {{比喩A}}
- {{技術概念B}} → {{比喩B}}