深いモデルに到達するためのユビキタス言語
実際にドメインを知るためには、ドメインの実践者（ドメインエキスパート）に話に聞き、彼らの知識からソフトウェアにとって重要な知識を取捨選択する必要がある。
開発者から見てその世界は、「配送しているのかな」「お客さんのところに届けるのかな」というようにぼやっとしか見えず、中で何が行われているのか詳しくはわからない。そこで登場するのがドメインエキスパートだ。ドメインの中がどういうものなのか、ソフトウェアが適応すべき対象がどんなもので、どんな形なのか。ドメインエキスパートと協力してドメインを捉え直す。これにより、開発者にもドメインがはっきり見えてくる。
例えば、ドメインエキスパートの「運送記録を残したい」という要求に、開発者が「正規化も必要ですし、FromとToの地点コードを地点テーブルで管理して、運送処理をコミットしたときにレコードを挿入して実現しよう」と技術的な言葉で返してしまうと、「よくわからないけど、つくってくれるんだな」とドメインエキスパートはそれ以上何も言ってくれなくなる。すると、どうなるか。完璧につくったと思っても、ドメインエキスパートからすると「これでは輸送と配送の見分けがつかない。使えない……」となる。開発者からすると、「輸送」と「配送」という言葉はこのときに初めて聞く。
では、どうすればよかったのか。ドメインエキスパートが「運送記録を残したい」と言ったとき、開発者が言うべきことは「運送記録は支店から支店への記録でいいですか」と自分が把握していることの確認だ。すると、相手は「この人は運送には、輸送とか配送があることを知らない」と気づく。こうした会話を続けていくことによって、最終的に、ドメインに沿ったモデルをつくることができる。
ドメインエキスパートとの間に断絶が起きないよう、共通の言葉でたぐり寄せてくのだ。このように、開発者とドメインエキスパートがコミュニケーションする際の言葉をドメイン駆動設計では「ユビキタス言語」と呼ぶ。
ただ、勘違いしてはいけないことがある。ユビキタス言語は会話をするための共通基盤の1つであって、エキスパートの言葉を収集した単語帳ではない。例えば、図の開発者とエキスパートの会話に出てくる「ミルクラン」はおそらくドキュメントにも書かれるだろうし、メソッド名になる。だからといって、ドメインの専門用語を羅列したものではない。
彼らの言葉を使ってドメインモデルをつくることではなく、エキスパートとの会話を通してドメインの事物について詳しく知り、ソフトウェアにとって有用な知識か、そうでないのか、えり分ける。エキスパートが知っているのはドメインの事物であって、ドメインモデルを知っているわけではない。開発者とエキスパートが協力してドメインモデルを作り上げる。モデリングは、できること／できないことを交えて、その事物（知識）の捉え方を変える作業であり、主体となるのは開発者だ。
成瀬氏は自身の経験談も含め、エキスパートとの会話の重要性を強調する。大事なのは話し方、それ次第で非常に深いモデルに到達することもできる。ドキュメントには絶対表れないニュアンスをキャッチするために使うのがユビキタス言語なのだ。
もう1つモデリングで重要な概念に「コンテキスト」がある。日本語では「文脈」と訳されるが、同じ言葉でも文脈、前後関係によって意味が異なるということに留意が必要だ。例えば、ECサイトを例に考えてみよう。ユーザーが注文する、その注文をドメインのスタッフたちが処理して配送して、商品を届ける。ユーザーからすると「注文」だが、ドメインのスタッフからすると「受注」、2つの視点がある。この2つの視点を分けて、境界づけられたコンテキストと捉えるのだ。ECサイトのフロントの世界とバックエンドの世界を分ける。コードも分け、パッケージや名前空間も分ける。それによって、同じ「注文」のクラスでありながら、注文と受注を分けることができる。
ただ、分けてしまうとお互いのことがわからなくなってしまうので、保護するためにコンテキストマップを作成する。
例えばECサイトのフロントの開発者が「注文」を直したいとなった場合、この図を見れば、バックエンドの「注文」がつながっていることがわかる。すると、修正する前にバックエンドの開発者に相談してみようとなる。こうしたチームビルディングもドメイン駆動設計には包括的に含まれている。
