Java EE勉強会

DDD / SPECIFICATION

SPECIFICATION (P224〜P227) †

要約 †

  • [文脈の説明]
    • どんなアプリケーションでも、Boolean を返すだけの簡単な検査メソッドがある。例えば Invoice クラスの isOverdue() 。 
      public  boolean isOverdue() {
  Date currentDate = new Date();
  return currentDate.after(dueDate);
}
  • しかし、全てが簡単なわけではない
  • [問題についての説明]
    • 大抵、Invoiceクラスを肥大化させないようにしようと試み、ルールをアプリケーション層に書こうとする。
    • ルールはドメイン層に在るべきだが、Invoiceには収まらない上に、条件分岐で肥大化したメソッドになってしまう。
    • 論理プログラミングであればルールを述語で明快に表すことができるが、論理パラダイムの中だけの話。
    • オブジェクトでも論理的なルールの実装が試みられたが、明確なのは、考えは魅力的でも完全な実装は大仕事だということ。
  • 問題サマリ
    • ビジネスルールはENTITIESやVALUE OBJECTSのどれかの責務とは限らず、その種類と組み合わせは、ドメインオブジェクトの基本的な意味合いを飲み込むことができるが、ドメイン層からルールを出してしまうのは、ドメインコードがモデルを表さなくなるので良くない。(P225-2)
    • 論理プログラムは”述語”の組み合わせでルールを書けるが、オブジェクトで実装するのは厄介というのは一般的。(P225-3)
  • [問題の解決方法についての説明]
    • 幸い、論理プログラムで完全に実装する必要はなく、述語の概念を借りて、Booleanに評価するだけのオブジェクトを作ることができる。
    • 新しいオブジェクト(SPECIFICATION)は別のオブジェクトの状態に規制かける。
    • 複数の用途があるが、基本概念はどんなオブジェクトでも検査できるということ。
  • 解決方法サマリ
    • ある目的に特化した述語ライクなVALUE OBJECTSを作成する。
    • SPECIFICATIONは、オブジェクトがいくつかの評価基準を満たすか満たさないかを決定する述語である。
    • 多くのSPECIFICATIONSはシンプルで特化した検査で、複雑な場合は、シンプルなSPECIFICATIONを結合する。（→次の章で）
    • SPECIFICATIONはドメイン層の中で規則を守る。
    • 規則が完全なオブジェクトなので、デザインはモデルの、より明白な反映かもしれない。
    • FACTORYでSPECIFICATIONを構成する。
＊＊＊
  • SPECIFICATIONの基本概念は非常に簡単なので、ドメインモデルの問題について考えるのを助るが、MODEL-DRIVEN DESIGNは概念を言い表す有効な実装を必要とするので、パターンがどう適用されるか少し深く掘り起こさないとならない。ドメインパターンはUMLの為だけでなく、MDEL-DRIVEN DESIGNのプログラミング問題を解決する。(227-1)
  • 適切にパターンを適用すれば、ドメインモデル問題への対処の仕方を身につけ、有効な実装を見つける何年分もの経験を得られる。パターンは料理の本ではなく、経験のベースから解決策を見いだし始めることをうながし、共通言語を与えるもの。(227-2)
  • 重要なところだけざっくり知りたいかもしれないが、きちんと論議しておくと後で楽。(227-3)

担当者のつぶやき †

みんなの突っ込み †


まとめ (議事録) †

Menu