ユビキタス言語についての考えの整理

(この記事は、ユビキタス言語について、自分の考えを整理するために書いたものです。)

DDDは分類法の一つという側面がある。一番大きな分類は、境界づけられたコンテキストだ。境界づけられたコンテキストはある業務領域に対応する分類の枠だ。ECサイトなら商品発送で一つのコンテキスト、請求処理で一つのコンテキスト、くらいの単位だ。

コンテキストは名前空間として働く。ドメインの用語はコンテキストの内部だけで有効だ。コンテキストを越えると同じ言葉であっても別の概念として扱わないといけない。

例えば発送処理と請求処理でコンテキストを分けているとして、それぞれのコンテキストで「顧客」という用語を使っていても、それらは別の概念だとみなさないといけない。

それぞれのコンテキストの顧客は共通のこともあるけど、業務が異なるので違う振る舞いを期待する。そういうのは別の概念として分ける。実装時にはそれぞれのクラスはそれぞれのコンテキストの中に別のクラスとして実装する。

このようにコンテキストの内部でだけ有効な用語を関係者みんなで使いましょう、それをユビキタス言語と呼びましょう、というのがユビキタス言語だ。

ユビキタス言語をうまく作用させるには、みんな(開発者もドメインエキスパートも)がユビキタス言語に則った用語を使うこと、ドメインモデルにもユビキタス言語を使った名前付けにすることが必要だ。

同じ言葉を使ってコミュニケーションすることで、ドメインを効率的に学習していくことができる。ドメインについての質問をユビキタス言語を使って行うことで、共通の言葉を使って概念を整理していくことができる。

それらのドメインの概念は、そのままプログラムでも表現する。そのために、パッケージ名、クラス名、メソッド名にもユビキタス言語をそのまま使用する。会話している言葉と同じ言葉を使ってプログラムを名前付けするために、翻訳しながらプログラムを読み取る必要がなくなる。

(コンテキストの中の)ドメインモデルの分類にはユビキタス言語を使うことになる。クラス名にはユビキタス言語で定義された用語が使われるし、用語間の関係はパッケージでグルーピングされる。パッケージの名前にもユビキタス言語で定義された用語が使われることもある。

ドメインモデルをユビキタス言語で分類するためには、ある用語がドメインの中のある一つの概念と結びついてないといけない。そうでないと曖昧な責務になってしまうだろう。あとはある用語が2つ以上の意味に使われているといけない。

ユビキタス言語これらの性質を満たしているというのが、DDDがうまく動くはず、という根拠になっていると思う。

なぜ ユニークな概念に紐づくユビキタス言語を作ることが可能かというと、それで実際の業務が回っているから、というのが根拠になっているのではないかと思う。業務を回しているということは、曖昧な用語を使ってコミュニケーションロスが発生していないはずなのだ。

例えば新しく田中さんが職場に入ってきて、すでに田中さんがいた場合、田中博、田中太のような感じで、自動的にユニークで誤解のない呼び名が生まれるはずなのだ。業務で扱っている言葉であれば、それが誤解を生むような用語であれば業務が回らないようになってしまう。

業務を回しているということは、そのような事態は発生しないということを保証している。なので、ドメインエキスパートと開発者の間で共有できるユビキタス言語を作ることが可能なのだ。