『エリック・エバンスのドメイン駆動設計』読書メモー第2章

今回は『エリック・エバンスのドメイン駆動設計』の第2章のメモを紹介する。
例によってメモなため、不正確、不明瞭なところがあると思うでの、ツッコミをいただけるとすごくありがたい。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

第2章は、ユビキタス言語を中心とした、コミュニケーションとコミュニケーション・ツールが主なテーマだ。

ユビキタス言語とは、開発者とドメイン・エキスパートがシステムにたいして共通に使用する言語だ。
ユビキタス言語は、ドメイン・モデルの図示やドキュメント、そして、プロダクトコードにも使用される。

ユビキタス言語の必要性は、開発者とドメイン・エキスパートとコミュニケーションこそが、システムの価値に直結するからだ。

そもそもエンジニアがDBやネットワーク、その他システムにまつわる用語をドメイン・エキスパートに使用しても理解できる人たちごく一部だ。
そのため、エンジニアの専門用語を多用した説明は、当然ながら「わかりにくい」と不興を買いやすい。

問題は、不興を買うだけでなく、「わかりにくい」言葉をドメイン・エキスパートとのコミュニケーションの時に常に翻訳しないといけないコスト、意味を取り違えるなどの齟齬を生むということだ。

もしも、開発者とドメイン・エキスパートが同じ言葉で違うものを指していて、そのままシステムが作られたとしたら、システムの価値を著しく減じてしまう。

システムがビジネスの役に立ち、価値を発揮するためには、ドメイン・エキスパートのもつ知識を活かしシステムを作り込むことが不可欠だ。
だからこそ、ドメイン・エキスパートと開発者のコミュニケーションが阻害され、ただし情報交換ができないことは、システムの価値を減じることになる。

こうしたことを防ぐためにも、そして、システムのビジネスにおける価値を高めるためにも、ドメイン・エキスパートと開発者は豊かで充実したコミュニケーションを行う必要がある。

その方法として、開発者とドメイン・エキスパートがおなじ言葉をつかうというユビキタス言語をもつことが有用なのだ。
良質なコミュニケーションこそが、価値の高いシステムを生むのだ。

最低限の状態

モデルに基づいたこの言語（ユビキタス言語）は、開発者の間で使用されなければならない。それも、システムにおける成果物を記述するためにも使われなければならないのだ。開発者が使うのと同じモデルによって提供される言語は、開発者とドメインエキスパートが互いに意思疎通をする際にも用いられなければならないし、ドメインエキスパート同士が要件や開発計画、あるいは機能を伝え合う際にも用いられなければならない。言語が広く使用されるほど、理解もよりスムーズに進むようになるのだ。(p.25,カッコ内はMr_K_Oによる補足)

この最低限の状態にたどり着くのはものすごく難しい、と思う。
受託開発をする際には、顧客の内部にも様々な組織と文化があり、その組織と文化により違う言葉を使っていることもあるからだ。
とくにプロジェクトが進行していると、すでにプロジェクトとしての文化がつくりあげられており、プロジェクト内部で言葉の意味を作りかえたり、整えたりすることは難しい作業になる。

また、自分たちの言葉は変えたくない、という要望もある。

言葉を統一する有用性は、開発者のみならず顧客もすぐに理解してくれるし、言語が不統一になっていることに問題意識をもっていることも多い。

しかし、この作業に着手するとドメインエキスパートと開発者、そして、ドメインエキスパートが所属する組織内部でも、調整が必要になる。

なによりも納期内にできる限り多くの機能を手に入れたい、というプレッシャーが多すぎると、エリック・エバンスがいう最低限の状態に到達する作業が蔑ろにされることが多い。

契約された機能のリストを消し込むことが優先され、プロジェクトの足元を整える作業がおろそかになる場合もある。

言葉の意味が統一されたときの有効性は経験が乏しいが、言葉の意味が不統一だったときの混乱は経験しているため、エリック・エバンスがいう最低限の状態にたどり着くことは、有効だと思っている。

ユビキタス言語の変更はモデルの変更を意味する

ユビキタス言語のある言葉が変更されるということは、言葉の概念がかわったということだ。
ドメインモデルはその名のとおり、ある領域における概念のモデルだ。

何かを指す言葉が変更されれば、既存のモデルの関係性やもっている属性や振る舞いが変更されることが多いだろう。
また、新たに何かを指す言葉が追加されれば、ドメインモデルに新しい概念を指すモデルが追加される。

また、ユビキタス言語はコードにも反映されているので、コードレベルでの変更が行われ、リファクタリングも発生するだろう。

話すことはモデルを改良する最善の手

開発者もドメイン・エキスパートも会話すること、荒削りな表現に気づくことができる。
会話をすることで、お互いが同じ言葉を別の意味で解釈していたり、その場で違いを認識して解消したりできるからだ。

モデルは図ではない

勘違いをしがちなのが、モデルを書いた図をモデルと勘違いすることだ。
モデル＝図ではない。

この勘違いが問題になるのは、図が完璧でなければならないという思い込みをうむことだ。
もっといえば、モデルの全てを図で表現しようという勘違いをしてしまうことだ。

ユビキタス言語によって構築されるモデルの詳細は、コードになる。
そのため、詳細を図示する必要はない。

図はコミュニケーションの目的によって使い分けるべきだし、コミュニケーションやモデルの理解に役立たないのであれば、詳細を表現する必要はない。

ドキュメントはコードと会話を補う

コードは詳細であり、モデルをどのように実現しているか、Howを雄弁に語る。

一方で、どうしてそのようなふるまいが必要なのか、については不明瞭だ。
コードが書かれた背景はなにか、設計の意図を説明するものがドキュメントだ。

そして、図と同様に、コードの詳細をドキュメントにするべきではない。
すでに、コードが表現していることをドキュメントでも行うことは作業の重複だ。