Wiki
DomainDrivenDevelopment / 第2章
- 開発者による抽象化は、自分たちの設計を支えて履いても、には理解されないかもしれない
- チームメンバのうち数人は、なんとか両者の言語を理解できるようになるものの、情報の流れにおいてボトルネックになってしまうし、その通訳も正確ではない
- 通訳することでモデルの概念を混乱させてしまい
- コードの破壊的なリファクタリングにつながる
- 通訳にかかる労力のせいで、知識と考え方に関する交流が妨げられてしまう
- ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている
- また、モデルの中で明示されたルールについて議論するための用語も含まれている
- モデルを言語の骨格として使用すること
- ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべき * 開発者は、設計を妨害することになる曖昧さや不整合に目を光らせるべき
- 機能を説明するにあたって、ビジネスの専門用語や、門外漢によるその意訳が使われているのがわかるだろう
- 人間は視覚的、空間的能力を持っているので、グラフィカルに要約することで、情報を素早く伝達して処理できる
- それと同じように、文法と意味を持つ言語に対して我々が生来持っている才能を活かして、モデルの開発を推し進めることができる
- 抽象的すぎる?
- ドメインエキスパートがモデルを理解できないとしたら、モデルに何か問題があるのだ
- [Q] こうした方言は、同じドメインに関して、異なるモデルを反映した別の語彙を含んでいてはならないのだ
- 問題が発生するのは、モデルや設計の全体を伝えるのに、UMLを使うことを強いられていると人々が感じた時である
- UML図はモデルの最も重要な側面のうちの2つ、すなわち、モデルが表している概念の意味と、オブジェクトが何を行うことになっているかを伝えられないのである
- すべてを網羅したオブジェクトモデル図や、UMLで描かれた網羅的なデータベースリポジトリを避ける
- 図が表現しているのは、考え方の骨格なのだ
- モデルは図ではない
- [Q] 書かれたドキュメント？
- 一片のコードが引き起こす振る舞いこそが現実なのであって、そこからは逃れられないのだ
- それでもなお、メソッドの名前は、曖昧だったり、誤解を招いたり、メソッドの内容に比べて古くなっていることがある
- テストの中の表明は厳密でも、変数名とコードの構成が伝える内容はそうではない
- このつながりは出来る限り直接的に保たれるが、それは自分を律した結果でしかない
- 正しいことをするだけでなく、正しいことを言うコードを書くためには、潔癖でなければならない
- ソフトウェア開発プロセスを推進する技術的なモデルは、厳密に刈り込み、機能を満たす上で必要な最小限のものにしなければならない
Updated