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

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

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

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

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

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

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

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

ドキュメントと図

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

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

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

実行可能な基盤

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

説明のためのモデル

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

ドメイン駆動設計読書会 第1章

ひょんなことからエリック・エヴァンスのドメイン駆動設計の読書会をすることになりました。

会話の中で理解したことをメモしていきます。今日は第1章です。

第1部 ドメインモデルを機能させる

• ドメイン：ユーザーの活動や関心についてプログラムを適用する対象領域
• ドメインモデル（モデル）：ドメインについての知識を抽象化したもの。特定の図ではなく、図で表された考え方そのものを指す。
• 言語：共通認識を共有するための記号・手段・取り決め。かな。
• エンティティ：データのかたまり

ドメインモデルの有用性

• モデルと設計の確信が相互に形成し合う
• チームメンバが使用する言語の基盤になる
• もっとも関心のある要素を区別する

ソフトウェアの核心

ドメインについて理解することで適切なソフトウェア開発を行うことができる。

第1章 知識をかみ砕く

PCB基盤の設計支援ツールを例に、モデルを作ることで共通言語を得、本当に関心のある事柄を抽出し、プロトタイピングを行い、イテレーションを回すこと＝知識をかみ砕くことで効果的なソフトウェア開発を行うことができることを説明

効果的なモデリングの要素

• モデルと実装を結びつける
• モデルに基づいて言語を洗練させる
• 知識豊富なモデルを開発する
• モデルを蒸留する
• ブレインストーミングと実験を行う

これにより知識をかみ砕く。

知識のかみ砕き

ドメインエキスパートと開発者チーム全員がモデルを噛み砕くことで、モデルにビジネスに関する深い知識が反映され、実装の助けになる。

継続的学習

継続的にドメインモデリングのスキル、技術的な知識、ドメインについて学習する。
初期の作業によって知識のかみ砕きというプロセスを発動させ、それによって以降の全作業を効率的に行う。

知識豊富な設計

これらのプロセスによって知識をかみ砕くことで、モデルを変化させ、実装をリファクタリングし、新しい知識をアプリケーションで使用することができるようになる。