ドメインとコードの同型性
ドメインの概念構造とコードの構造が直接マッピングされている状態。「ドメインの認知構造がコードに直接反映されている」ことを指す。
なぜ重要か
ドメインの言葉とコードの言葉が一致していれば、「ここを変えたい」という意図がそのまま「このコードを変える」に直結する。概念とコードの間に翻訳コストがかからない。
これによりフィードバックループが高速化する：
- 「要件が変わった」→「どのコードに影響するか」が自明
- 「バグがある」→「どの概念が正しくモデル化されていないか」が明確
- 「新機能を追加したい」→「どの型・モジュールに追加すべきか」が分かる
型による実現
型駆動開発の文脈では、型定義そのものがドメインモデルの表現になる。
// ドメインとコードが一致している例
type Order =
| { status: "draft" }
| { status: "paid"; paidAt: Date }
| { status: "shipped"; paidAt: Date; shippedAt: Date };
この型定義を読むだけで、注文の状態遷移（draft → paid → shipped）と各状態の不変条件が理解できる。ドメインエキスパートと開発者が同じ語彙でコードについて話せる。
ユビキタス言語との関係
Domain-Driven Designのユビキタス言語は、ドメインエキスパート、開発者、コードの間で語彙を統一することでこの同型性を実現するための実践。
同型性が崩れるとき
- 技術的な都合でドメイン概念とは異なるデータ構造を使うとき
- レガシーシステムのテーブル設計がドメインと乖離しているとき
- 複数のドメイン概念を1つのクラス/関数に詰め込んでいるとき
同型性が崩れると、認知負荷の「翻訳負荷」が増大する。
認知的距離との関係
同型性が維持されている状態 = ドメインのスキーマとコードのスキーマの認知的距離がゼロに近い状態。同型性が崩れるとスキーマ間の翻訳が必要になり、距離が増大する。フィードバックループが高速なのは、距離が小さいから変更の影響が自明に追跡可能だから。