くまごろーのプログラミングメモ

『ドメイン駆動設計』第2章エヴァンス本まとめ&感想

DDD

前回のふりかえり

第1章の主旨
- 知識をかみ砕くことで、チームの持っている知識が価値のあるモデルとして変わることができる。
- 知識のかみ砕きは、皆が持っている情報(ドメイン・技術)を集めて、大部分の意味を理解できるシンプルな見方を見つけようとする作業
気になったこと
- 知識のかみ砕きは具体的にどのようになされるのか？

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

キーワード：共通言語
- 共通言語のないプロジェクトの場合、開発者とドメインエキスパートの間で 通訳 が必要になる。
- 通訳自体が余分なコストになる上に、誤解のリスクも伴う。その結果生み出されるのは整合性の取れないソフトウェア
ユビキタス言語 がチームの共通言語になりえる
- ユビキタス言語≒ドメインモデル？(ここらへんよくわかっていない)
- ユビキタス言語はドメインモデルを元に構築された言語？
知識をかみ砕いて役立つモデルを作り出すには...
- ユビキタス言語を使ってコミュニケーションをとること
- その用語(表現)で合っているのか絶えず議論・実験してユビキタス言語を変更していく(=ドメインモデルを変更していく)

知識をかみ砕くための方法

モデルを言語の骨格として使用する。
チーム内のすべてのコミュニケーション(会話・図・ドキュメント)とコードにおいて、その言語を厳格に使用する。
言語を使う中で問題があれば、代わりの表現で実験する。問題なければ表現を更新(≒モデルを更新)し、それをコードにも反映させる。
会話の中で用語の意味・用法を混同していることがわかれば、認識合わせを行う。
ユビキタス言語に対する変更＝モデルに対する変更と認識する。

※　↑の中で、メンバーがユビキタス言語に対して行うこと

- ドメインエキスパートは、理解を伝えるためには使いにくい・不適切な用語があれば異議を唱える
- 開発者は、設計を妨害するあいまいさや不整合を見逃さない

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

モデルを改良する最適な方法の一つは、話してみること。粗削りな表現は聞けばすぐにわかる。
- (ドメインモデルの)ユビキタス言語を議論で使用すると、ニュアンスを互いに教え合うことになる。
- 図とドキュメントでは起こりえない方法で、会話で使う言語を自然に共有するようになる。 →　より簡単な表現方法を発見して、図やコードに落として込んでいく

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

単語の意味というのは、つかみどころがない(価値観・立場によって定義が異なる？)
ドメインエキスパートと開発者が同じ言語(ユビキタス言語)を使う。
- ユビキタス言語(モデルに絶えず反映されている)の意味がドメインエキスパートに理解できないものであれば、モデルに何か問題があることがわかる。

ドキュメントと図

図をどれだけ詳細にしても、オブジェクトのふるまいとオブジェクトに対する制約は簡単に図示できない。
図はあくまでコミュニケーションと説明の手段。 モデルは図ではない
- 全てを網羅した図では、説明もできないしコミュニケーションもできない。
→ 図をコミュニケーションに使う時は、オブジェクトモデルにおいて概念的に重要な部分を示す、 簡略化した図 を用いる。
XPなどは図やドキュメントを極力排しているが、コードに設計の意図や構造への洞察を込めることは難しい。
- そのような面でドキュメント・図は 役に立つ。
ただし、(役に立つ)ドキュメントはプロジェクトの活動に取り込まれていなければならない。(コードと連動し、最新化されていなければならない)
- ↑を実現するために、ドキュメントを最小限にし、目的をコードと会話の補足に絞る。

気になったこと・思ったこと

ユビキタス言語を最初辞書的なものと想像していたが、実際はドメインモデル図のようなもの？
知識をかみ砕くことは、共通(のコンテキストを有しているという前提がある)言語を元に、業務担当者(ドメインエキスパート)と開発者が業務のモデルを明らかにしていくこと？共通言語自体をモデルとしてブラッシュアップしていくこと？
- 今のところ、共通言語を元にしたドメインエキスパートと開発者のコミュニケーションがめちゃくちゃ重要そう
- 「より簡単な表現・より良い表現を見つけて言語を変更する(=コードに反映する)」という話がそこかしこで出てきている
最後に モデル駆動設計 という言葉が突如登場したが、今のところあまりよくわかっていない

参考