第9章 仕様

[im-higashi]

9章

仕様

• 以下の点、述語(predicate)について

p227
ビジネスルールは、明らかなエンティティや値オブジェクトの責務のどれとも合致しないことがしば
しばあり、その多様性と組み合わせによって、ドメインオブジェクトの基本的な意味を圧倒しかね
ない。しかし、ルールをドメイン層から取り出してしまうのはさらに悪い。ドメインコードがモデルを表
現しなくなってしまうからである。
論理プログラミングは、「述語」と呼ばれる、独立した結合可能なルールオブジェクトの概念を
提供するが、この概念をオブジェクトで完全に実装するのは面倒である。また、あまりにも一般的
なため、より特殊な設計と同様に、多くの意図を伝えることもない。

p228
特殊な目的を持った述語的な値オブジェクトを明示的に作成すること。仕様とは、あるオブ
ジェクトが何らかの基準を満たしているかどうかを判定する述語である。

• 仕様のメリットとして感じたこと

  • 仕様によってルールがドメイン層に維持される
  • 単一責任の原則に沿う
  • UNIXの以下の原則とも近い
    • 「すべてのプログラムをフィルタとして設計する」という考え方とも一致する
    • スモール・イズ・ビューティフル
    • 1つのプログラムには1つのことをうまくやらせる

• 仕様の適用と実装について

  • 検証、選択、要求を満たせばそれは述語としてSpecificationオブエクととしておくことでルールの一貫性が出る
  • 検証
    • 述語そのもの
  • 選択
    • 述語を使っての抽出
      • リポジトリとの結合によって仕様がクエリを制御できるし、仕様のテスタビリティが向上する
  • 生成
    • ジェネレータとの違いやメリットは？

• 疑問

  • 述語は副作用のない関数でない場合というのはあっても良いのだろうか

• 例9.5 格納

  • P241

依頼されたソフトウェアではない
ドメインの理解を通じてこういった一貫性のあるかたちで発見があるのでは

• P242 アプリチームとサービスチームとの連携

フィードバックループをより完全なものにするには完全に動くシステムが必要になる
この完全に動くシステムの定義は？

スタブでは不完全でアプリチームからフィードバックをもらえる程度に
仕様を満たしいることが最低限、最適化未実施でも問題ない
ただし、テストがないとフィードバックに対応できない

この辺り度の程度のレベルのものを指すのか？

• p245

コラム
プロトタイプで進める場合でも他のチームにはインターフェイスと実装を分離するのは有益
実装の最適化はあとで可能なことと
ドメイン駆動であればインターフェイスが明確になるとともに
お互いに気にするものが最小化される点が利点かと

ジェネリックあれば・・・