前回のふりかえり
第9章(前半)の主旨
- 深いモデルというのは、ドメインの中心となる概念や抽象を含んでいる。
- 深いモデルを作るには、ドメインの本質的な概念をモデルで表現することが必要。
- 多くの概念は暗黙的で認識できないので、それを下記の様な方法で掘り出す必要がある。
- チームの言語に耳を傾ける
- 設計のぎこちない点やエキスパートの発言で、矛盾してそうなところを詳しく調べる
- ドメインに関する文献を読む
- 大量に実験する
- 多くの概念は暗黙的で認識できないので、それを下記の様な方法で掘り出す必要がある。
第9章 暗黙的な概念を明示的にする(仕様)
- 仕様とは、エンティティや値オブジェクトの責務に合致しないビジネスルールを表すためのオブジェクト
- ビジネスルールには、エンティティや値オブジェクトの責務にどれにも合致しないことがある
- そのようなルールを表現するために、論理プログラミングで言う「述語」の概念を借用した、評価の結果ブール値を返すオブジェクトを作成すればよい → それが仕様
仕様の適用と実装
以下の3つの目的の1つでも当てはまれば、オブジェクトの状態を定義する必要がある
- オブジェクトを検証して、何らかの要求を満たしているか、何らかの目的のための用意ができているかを調べる(検証)
- 仕様という概念を最も直接的に示す利用法
- コレクションからオブジェクトを選択する(選択)
- 要求に適合するオブジェクト生成を定義する(要求に応じた構築)
- まだ存在していないオブジェクトの条件を定義している。仕様を用いることで、生成物を明示的に制約することができる
→ 仕様パターンを適用することで、実装が異なっていても、一貫性のあるモデルを使用できる
思ったこと・気になったこと
- まとめはしたが、正直あんまりよくわかっていない。
- 検証の例示で「クライアントクラスに判定メソッドを書く」という説明があった。でも仕様はビジネスルールを表すためのオブジェクトの一種という説明もある。クライアントに判定処理を書いてはいけないのでは?一通り読み進めたらここに戻ってこよう。