Domain Model(Domain Logic Patterns)

概要

• ドメイン（問題領域）のオブジェクトモデルを作成し、そこにドメインロジックと処理対象データを持たせるパターン。
• 一見したところDBモデルと似ているが、データと処理両方を持っている点が異なる。
• 条件分岐で処理を実行するかわりに、オブジェクトネットワークをセットアップする。作成されたパスをたどりながら処理を実行することで、目的を達成する。つまり、オブジェクト構造自体がアルゴリズムになる。
  

メリット

• 複雑で、変更が絶えず発生するロジックの修正コストが低い。
• ロジックの重複が少なく、規模は比較的小さくできる？
  

デメリット

• トランザクションを多数のオブジェクトの相互作用によって実現するため、多数の開発者による並列開発が困難。
• （少なくとも、慣れていない人にとっては）設計が難しく、理解も難しい。
  
• データベースとのマッピングが困難。
  

注意
ドメインオブジェクトに置くべきかどうか迷うロジック
ドメインオブジェクトは、ある概念を表したアプリケーション内で1つしか存在しないオブジェクトになるため、そのオブジェクトに関連はしているが、特定の 画面でしか必要のないロジックをすべてオブジェクト内に取り込むと、オブジェクトが肥大化してしまう。こういうロジックはユーティリティクラスや Transaction Scriptとして実装したくなるが、そうするとこの部分の処理が重複しやすくなり、結果的にアプリケーションが複雑になりやすい。
Fowlerの経験上、オブジェクトの肥大化はあまり起こらず、対処も容易なため、こういった操作もドメインオブジェクト内に置くことをすすめている。

他のレイヤとの関係
複雑なドメインロジックは変更が頻発するので、修正・ビルド・テストが容易になっていることが重要。そのために、他のレイヤへの依存を最小限にするのが望ましい。

バリエーション
二つのスタイル
シンプルなドメインモデルは、1テーブルに対して1ドメインオブジェクトが対応づくようなスタイル。リッチなドメインモデルは、データベースモデルとは異 なり、継承・StrategiesなどのOOやGoFのパターンが使われおり、細粒度の多数のオブジェクトから成る。リッチなドメインモデルは複雑なドメ インロジックを構成するのに向いているが、DBとの対応づけが困難になる。リッチなドメインモデルにはDataMapperが、シンプルなドメインモデル にはActiveRecordが向いている。

Railsはデフォルトの永続化メカニズムがActiveRecordパターンの ActiveRecordなので、逆に考えるとロジックはシンプルなDomain Modelを指向しているんだろう。名前もActiveRecordの実装クラスはModelフォルダに置かれるし。となると、Railsではみんな、 ControllerじゃなくてModelにドメインロジックを書いてるってこと？Railsが普及すると、日本でも徐々にDomain Modelへの道が開かれるのかな。

使いどころ
　ロジックが複雑で、絶えず変更が発生するような場合。