-
ドメインモデル ＝ ソフトウェア開発の共通言語のコア ＝＞
ユビキタス言語 -
ユビキタス言語＝ モデルと実装をつなぐ重要な糸 、コードにもタスクを表現することにも使われる -
コミュニケーションのあらゆる媒体に浸透させることが望ましい(会話、図、ドキュメント)
-
共通言語がないと、ドメインエキスパートと開発者間で通訳が必要になる
→ 情報のボトルネックになる
→ 通訳のミスがモデルの破壊にも繋がる
→モデルと実装に乖離が出てしまう
（WFでよくある、アナリストがドメインを分析して、プログラマがトランザクションスプクリプトをかき、 全くドメインがわからないソースが出来上がる）
-
声に出してモデリングをする
⇨ 言語が曖昧な部分＝モデルの弱点があぶり出される ⇨ モデルの改良に繋がる ＝＞言語に対する変更がドメインモデルに対する変更と認識される（例） -
モデルを言語の骨格として用いることをチームに約束させること
-
モデルのユースケースを声に出して描写する
-
違和感があれば、言語を変更 → モデルに反映 ー＞ コードに反映
ドメインエキスパートは、不適切な用語や構造を指摘すべき＜＝ 伊藤さん共感開発者は設計を妨害する曖昧さや、不整合を指摘すべき
- モデルは図ではない 詳細はコードで表現する
- 適切に書かれたJavaにはUMLと同じくらいの表現力がある ＜＝ 共感
- すでにコードがうまくやっているところをドキュメントでもやろうとすべきではない
- ドキュメントはコードや会話での表現を補わなくてはならない
- 書くなら最新化しなければならず、それがプロジェクトの活動に織り込まれていなくてはならない
- モデルはドメインについての教材としての一面をもつ (XXXXXだとXXXXXがあって、、、)
- モデルのサブセット → 要点を捉えるよう調整されたモデル → 関係者の理解を助ける (UMLでなくても良い)
プロジェクト内でのコミュニケーションはドメインモデルに基づくようにしよう
- XXXXXで、現状共通言語はどんなものがあるか どうあるべきか