http://martinfowler.com/bliki/TypeInstanceHomonym.html

（更新：ユビキタス言語を使った扱い方のパラグラフを最後に追加）

『戦争と平和』は素晴らしい本だ。

あーあ、この本の表紙はボロボロだねえ。

上の2つの文では、どちらも「本」という言葉が使われている。 意味はまるっきり違うのだが、普段は特に気にかけることはない。

上の文の「本」は「著書」を表している（100年以上も前からある著書だ）。 下の文の「本」は、物理的な「モノ」を指している（おそらく100年も持たないだろう）。 後者の「本」は簡単に火をつけて燃やしてしまうことができる。 だが、前者の「本」は、私が火をつけたところでどうにもならないし、私よりも長く存続することは明らかだろう。 前者の「本」をいくつもハードディスクに入れたところで、後者より重くはならない。

このような曖昧性は自然言語においてはよくあることである。 「車」「樫」「プログラマ」などを考えてみれば分かるだろう。 両者を明確に区別しようとすると、哲学における記号論という薄暗い場所に迷い込んでしまうので、とりあえず、ここでは私の見解を述べておこう。

「本」という言葉は、複数の概念を持つ用語である。 最初に挙げた2つの文では、「本」は、「著書」と「物理的な一冊の本」を指していた。 おそらくここの読者はプログラマばかりだろうから、プログラミングのアナロジーを使おう。 「本」クラスが2つある。だが、2つのクラスの意味は異なる。 両者を区別するために、「LiteraryWork（著書）」クラスと「PhysicalCopy（物理的な本）」クラスという名前を付ける。 最初の文で「『戦争と平和』は（素晴らしい）本だ」と言ったが、「『戦争と平和』はLiteraryWorkのインスタンスだ」と言うことができる。 同様に、2番目の文章は、PhysicalCopyのインスタンスの特性について述べたものである。

この2つの概念は独立したものではない。 「right（右）」と「right（正しい）」のような同音異義語とは違い、両者には密接な関係がある。 「本（物理的な本）」は「本（著書）」を表現したものである。 だから私の『戦争と平和』の表紙はボロボロだと言うことができる。 同様に、私の「スバル レガシィ（物理的な車のインスタンス）」は「スバル レガシィ（車種のインスタンス）」と関係がある。 この関係性は非常に一般的で、オブジェクトモデリングやデータモデリングをやっている人には馴染みのあるものだろう。 同様の構造は「製品」と「製品型」にも見られる。 「本」と「本型」とは言うことはないが、関係は同じものである。

モデリングやプログラミングをしていると、異なる概念を表す用語に出会うことがある。 それぞれの概念は、別々のクラス名（あるいはテーブル名）としてコードの中に表される。 ドメイン言語に同音異義語がある場合は、異なる文脈で、異なる使い方がされることが多い。 Eric Evansは、これを「Bounded Contexts（文脈束縛）」と呼んでいる。 Jim Odellは次のように指摘していた。

”“「Mary had a little lamb（子羊）」は、獣医が使うのと、レストランの主人が使うのとでは意味が異なる。

型インスタンス同音異義語の問題は、文脈に密接に関係していても起こってしまう点だ。

ここで私が言いたいのは、このような状況におけるモデリングについてではなく（それはそれで色々言うことはあるんだが）、同音異義語が引き起こす曖昧さについてである。 この曖昧さが興味深いのは、引き起こす問題がまったく深刻ではないという点だ。 人間は複数の概念を問題なく切り替えることができ、取り違えてしまうことはない。 だが、会話のなかで様々な用語を使ってしまうと、会話が続かなくなってしまう。 私も会話や書き物のなかでやってみたことがあるが、すぐに迷子になってしまった。 規律が守れなくなっただけでなく、なんだかよく分からない精神状態になった。 （これは型インスタンスだけの問題でない。「go through the door we painted last week（先週ペンキを塗ったドアを通って）」が示すものも同様である。★）

私の専門であるオブジェクト指向設計で特に興味深いケースがある。 よく「オブジェクトにメソッドを追加する」と言うことがあるが、実際にはオブジェクトにメソッドを追加しているわけではなく、クラスにメソッドを追加している。 会議なんかでそのことを指摘する「学者ちっく」な人になってしまう時期もあるだろうし、 そこらへんを適当に言い切ってしまう時期もあるだろう。

結局のところ、同音異義語には絶対に気をつけるべきだ。 ソフトウェアにおける概念を区別し、それぞれ異なる名前を付ける必要がある。 ただし、混同する危険性のある文脈になるまで、会話のなかで明確に概念を区別できるとは思わないで欲しい。 我々の脳は曖昧性を自動的に解消してしまうからだ。

では、UbiquitousLanguageではこれは何を意味するだろうか？ まず、モデリングをして、異なる概念を認識する（同音異義語に気づく）。 異なる概念から名前を付け、それをユビキタス言語のなかで使用し、ソフトウェアとして表す。 名前には同音異義語を付けないようにするとよい。 文脈が図書館であれば、「本」という名前は付けずに、「Literary Work（著書）」と「Physical Copy（蔵書）」というふうにする。 曖昧さを無くすことで、ドメイン専門家に理解しやすくする。 ユビキタス言語に関わる人すべてにとって理解しやすくする必要がある。

特に新しいドメインを扱う場合、 最初のうちは常に同音異義語にアンテナを張っておかなければならない。 通常、同音異義語はドメインの中心の用語に表れる。 図書館における本がそうだ。 私はユビキタス言語をモデル化するためにインフォーマルなクラス図を使用している。 そして、同音異義語を根絶やしするのが良いだろう。