はじめに
以下の書籍のの第3章の引用+個人の考えです。
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
業務アプリケーションのコードの見通しが悪くなる原因
ロジックを持たないデータクラスを使ってデータの受け渡しをするとコードの重複が起きます。データクラスを参照できる場所であれば、どのクラスにでも、ロジックを書けてしまうからです。
-> APIで受け取ったレスポンスボディーをコンポーネント内でロジックを書くと、別コンポーネントでも同様のロジックが書かれる。
共通機能ライブラリが失敗する理由
汎用化のため使いづらい
汎用的に使えるように、引数にフラグやオプションが増え、使い方が分かりづらくなる。
用途ごとに細分化した共通関数
用途ごとに細かく分けると共通ライブラリのメソッド数が膨れ上がり、微妙な違いを理解してメソッドを使い分けるのが大変。
-> lodash。ファイルサイズめっちゃ大きい。クラスのメソッド内で使うのはアリ。
データクラスでの設計スタイルが広く使われる理由
- 1995年の業務アプリケーションはCOBOL、C、C++が主流だった
- Javaになっても従来の業務アプリケーションの方法を採用。
オブジェクト指向らしいクラス設計
- メソッドをロジックの置き場所にする
- ロジックをデータを持つクラス移動する
- 使う側のクラスにロジックを書き始めたら設計を見直す
- メソッドを短くしてロジックの移動をやりやすくする
- メソッドでは必ずインスタンス変数を使う
- クラスが肥大化したら小さく分ける
- パッケージを使ってクラスを整理する
上記のことは書籍読んでると「当たり前のことだよね」と読み進めることができるのですが、既存のアプリケーションコードを見直すとできてない箇所が多いです。
そのコードをみた人が既存の設計を踏襲し、どんどん見辛いコードが増殖する状況に・・・
ドメインオブジェクト
関連する業務データと業務ロジックを1つにまとめたオブジェクト
-> 業務データと業務ロジックを持つ。
-> メールアドレスや、名前など小さい単位で作る。
-> 小さなドメインオブジェクトを組み合わせて、より大きな関心ごとを表現する。
詳細な設計については第4章。
業務ロジックとは？
-> 業務上の会話で出てくるもの。
-> 例えばPostのドメインオブジェクトの場合、新しい記事を表示したい場合isNewのようなロジックが思いつく。フロントで受け取りやすいようにレスポンスボディを加工するようなロジックは業務ロジックではない。
三層 + ドメインモデル
引用：現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
三層＋ドメインモデルで関心事をわかりやすく分離する
-> 業務ロジックをプレゼンテーション層・アプリケーション層・データソース層に書かない。
| 名前 | 役割 |
|---|---|
| プレゼンテーション層 | UIなど外部との入出力を受け持つ |
| アプリケーション層 | 業務機能のマクロな手順の記述 |
| データソース層 | データベースとの入出力を受け持つ |
| ドメインモデル層 | 業務データと関連する業務ロジックを表現したドメインオブジェクトの集合 |