やったこと

• 現場で役立つシステム設計の原則 3章 読了

学んだこと

従来の設計とその問題点

データを格納する「データクラス」とロジックを記述する「機能クラス」の二つに分けるのが一般的。

問題点

開発が進むにつれ、あらゆるロジックが「機能クラス」に集約されていく。
結果として、以下の問題が発生する。

• 同じ業務ロジックが重複して記述される
• 見通しが悪くなり、特定の業務ロジックを見つけるのが困難に

■同じ業務ロジックが重複して記述される

データクラスは、どこからでも（三層アーキテクチャであれば、あらゆる層から）アクセスできるように設計されることが多い。

結果として、データクラスを使用したロジックは、どこにでも書くことができてしまう。

データクラスにロジックを書くことを是としない結果、以下の処理のセットがいたるところで記述されるようになる。

• データクラスからデータを取り出す
• 取り出したデータを使用して何らかの処理を行う

■見通しが悪くなり、特定の業務ロジックを見つけるのが困難に

「機能クラス」にあらゆるロジックを記述するため、開発が進むにつれて記述が膨れ上がり、目的のロジックを見つけるのが困難になる。

「データクラス」と「機能クラス」に分けるという設計は、オブジェクト指向の意図とは正反対

オブジェクト指向は、ドメイン知識について、データとふるまい（ロジック）を一か所にまとめて書くことを意図している。

従来の設計は、データとふるまいを分離するという、正反対の方向に舵を切っている。
従来の設計は、手続き型の設計である。
手続き型言語のやり方をオブジェクト指向でなぞった結果が、従来の設計の誕生だ...と、書籍では述べている。

データクラスの弊害

• アプリケーション層の構造が画面の構造に引きずられる
• アプリケーション層の構造がデータベースの都合に影響される

クリーンアーキテクチャ風に言うと、「詳細」側に依存してしまう設計となってしまう。

汎用クラスは使用されない

業務ロジックの重複を避ける手段として、「汎用クラス」が用いられる。

業務ロジック別に細かなニーズが異なる。
これに対応するために、以下のどちらかが取られる。

• 汎用クラスに引数を設定し、引数にて細かなニーズを満たすよう処理を分岐させる
  • 引数による処理の分岐を把握する必要がある
  • 引数が増えると、既存のコードが全部書き直し
• 細かなニーズ別にメソッドを用意する
  • 大量に生まれるメソッドの細かな違いを把握する必要がある

どちらの手段を選択しても、最後は「自分で書いたほうが早い」という結論となってしまい、誰にも使用されなくなる。

業務ロジックをわかりやすく整理するための基本アプローチ

• データとロジックを一体にして業務ロジックを整理する
  • あるデータについて、データそのデータを使用するロジックを、一つのクラスにまとめる
• 三層のそれぞれの関心事と業務ロジックの分離を徹底する

つまり、凝集度を上げる。

ここでいう凝集は、 「切っても切れない」関係。

凝集度が高い（≒「切っても切れない」）データと業務ロジックのみで構成されたクラスを設計していくことが、基本方針。

所感

データクラスを使用したロジックは、どこにでも書けてしまう問題について。
良くない書き方が可能な状態であれば、（将来含め）誰かが良くない書き方をする。
これは運用でカバーするのではなく、言語機能でカバーするべき。
今回の例だと、データクラスをパッケージプライベートで宣言し、他の層から見えないようにする...といった対策が考えられる。