ドメイン駆動設計読書会 第2章 コミュニケーションと言語の使い方

エリック・エヴァンスのドメイン駆動設計の読書会で理解したことをメモしていきます。今日は第2章です。

第2章 コミュニケーションと言語の使い方

ユビキタス言語：ドメインモデルが対象とするスコープ内で使用するドメインエキスパート、開発者間での共通言語
プロジェクトではモデルによるコミュニケーションのみでなくユビキタス言語による会話が不可欠である。
ユビキタス言語は使用中にひっかかりや違和感があれば変更されなければならず、それに伴いモデルも変更されるべきである。

声に出してモデリングする

ドメインモデルを改良するためには声に出してみるとよい。表現すべきことをより簡潔に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること

1つのチームに1つの言語

ドメインエキスパートが抽象化したモデルを理解できないからといってドメインモデルから遮断したり、別のモデルを作成してはいけない。ドメインエキスパートがモデルを理解できない場合には、モデル側に何らかの問題がある。
ユビキタス言語を用いることにより、開発者間の会話やドメインエキスパート間の議論、そして、コードそのものでの表現がすべて、共有されたドメインモデルから得られた同一の言語に基づくようになる。

ドキュメントと図

UML図はオブジェクト間の関係性を表現するのには役立つが、オブジェクトの概念の定義については表現しきれない。また、実装の詳細はコードで表現されるべきである。モデルは図ではない。図はモデルについてコミュニケーションするためのツールである。

書かれた設計ドキュメント

ドキュメントはコードや会話でのコミュニケーションを補わなければならない。アジャイルやXPではコード自体を設計ドキュメントとして扱うが、「なぜそうするのか」という背景の部分までは表現できない。ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない（むしろその方法を知りたいんだけど、詳細なドキュメントについて指示するつもりはないと筆者は書いている）。
ドキュメントはプロジェクトの活動に取り込まれていなければならない。ユビキタス言語に耳を傾け、ドキュメントとの相互作用を観察することで、活動にドキュメントがプロジェクトの活動に取り込まれているかどうかを確認できる。

実行可能な基盤

コードが引き起こすふるまいこそが現実である。コードによって伝えられるメッセージができる限り正確であるためには、規律を守り、設計について特定の考え方をし、要件を書くのに使用されたユビキタス言語に基づいていなければならない。

説明のためのモデル

実装、設計、チーム内のコミュニケーションの根底にあるモデルは1つだけであるべきだが、説明のためにソフトウェア設計とは直接関係しないモデル（この文脈だと図と言ったほうが正確な気がする）を使用することは人々の理解を助ける。