業務ロジックの整理　〜三層＋ドメインモデルの構築〜

クラスとはデータとロジックを一つのプログラミング単位としてまとめるための仕組みであり、データをインスタンス変数として持ち、それに対するロジックをメソッドに書くのがオブジェクト指向におけるクラスの本来の使い方である。

三層アーキテクチャを採用しても、データクラスと機能クラスを分ける手続き型の設計のままでは以下の状況が起こりやすくなる。

この要因としては、手続き型の設計では業務ロジックが入り組んでくると次の問題が顕著になるからである。

プレゼンテーション層、アプリケーション層、データソース層がそれぞれデータクラスにアクセスできるため、
同じ業務ロジックがあちこちに書かれる
どこに業務ロジックがか書いてあるか見通しが悪くなる
業務ロジックをアプリケーション層に集約したとしても
- 機能クラスが画面と密結合になる
  - 画面と機能クラスを一対一で関連付けると、複数の機能クラスでロジックが重複する可能性が高い
- 機能クラスがテーブルのCRUD操作単位での設計になる
  - たとえば注文テーブルのCRUD操作と出荷テーブルのCRUD操作をそれぞれ別の機能クラスとして実装した場合、合計金額導出ロジックをどこに置くべきか明確でなくなる
共通機能ライブラリを作ったとしても
- 共通化できそうなロジックでも、ユースケースによってニーズが微妙に異なる
  - それらのニーズに対応するため、メソッドにオプションやフラグを渡すことになり、使い方が煩雑になる
- そうなると、用途ごとに細分化されたメソッドが大量に定義され、結果的にコードが重複する

メソッドをロジックの置き場所にする
- クラスにインスタンス変数を返すだけのゲッターメソッドだけがある状態ではデータクラスと何も変わらない
- 何かしらのロジックをもたせる（データをgetする側のクラスではそれを使って何かをしたいはず）
- その「何か」のロジックが重複することを防げる
メソッドは必ずインスタンス変数を使う
- もし使わない場合、そのメソッドの置き場所は不適切
- データを持つクラスに移動させる
クラスが肥大化したら小さく分ける
- 関連性の強いデータとロジックを新しいクラスに分ける
- 凝集性が高まる
- 関連性の強いデータとロジックをもったオブジェクトをドメインオブジェクトという
- 小さなドメインオブジェクトを組み合わせて大きな業務の関心事を表現するクラスを設計する

データとロジックをドメインオブジェクトとして小さな単位に分けて整理すると、クラスの数が膨大になるため、整理する必要がある。

業務アプリケーションの対象領域（ドメイン）をオブジェクトのモデルとして整理したもの（ドメインオブジェクトの集合）をドメインモデルという。

三層＋ドメインモデルの各レイヤーの役割は以下のようになる。