ソースコード管理についてまとまってると聞いたので読む。
新たな学びor改めて重要だと思った内容をメモします。(なので既知な内容は書かないので、メモは薄くなるかも)
1章 小さくまとめてわかりやすくする
- 命名を省略してつけるな。
- 例: quentity を qty にする
- ローカル変数が変更するなら、その都度変数使おう
- 説明用の変数の導入
- 値オブジェクト使おう
- 値は不変にする。完全コンストラクタ大事。
- コレクションオブジェクト。配列とかの操作をカプセル化する。
2章 場合分けのロジックを整理する
- else句は基本書かないようにする
- 多態(ポリモーフィズム)
- 列挙型
- Rubyで使うなら enum ＆ freeze する
3章 業務ロジックををわかりやすく整理する
- DTOパターン → データの受け渡し専用のクラス
- 3層アーキテクチャ → プレゼンテーション層/アプリケーション層/データソース層
- メソッドは、判断/加工/計算のロジックを実行して初めて役に立つ
- データを返すだけのgetterは無意味
ドメイン駆動の話。
4章 ドメインモデルの考え方で設計する
- ドメインモデルであれば、業務ロジックやデータを内包できるので可視性🙆♀
- 手続き型アプローチ
- トップダウンのアプローチ
- オブジェクト指向型アプローチ
- ボトムアップのアプローチ
- ドメインモデルで設計するときに、依存させるようにするのはNG
- ドメインオブジェクトは、アジャイルで改善し続ける
業務知識は最初から完璧ではないので、アプデしていくのが大事
5章 アプリケーション機能を組み立てる
- 業務ロジックはサービスクラスに移管しない
- サービスクラスに業務ロジックを書きたくなったら、それはドメインモデル改良の余地がある
- 画面の複雑さ、データベースの入出力をサービスクラスに任せない
- 業務の視点からの記録と参照型の関心をRepositoryとして宣言する手法
- データベースの操作の詳細を、サービスクラスに意識させない工夫
参考になる→ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ！！！
6章 データベース設計とドメインオブジェクト
プログラムがわかりにくくなっている原因がデータベース設計の場合 という章
- NULLが入るテーブルを許すな
- どうしてもNULL値が必要ならカラムをわけましょう。NULL=未知 なので ダメです
- 省略命名を許すな
- カラムを追加するのであれば、別テーブルを作成して外部キー制約をつけること
- 既存テーブルに追加して、NULL制約を防ぐため虚のデータをいれることはダメ
データベースの本質は事実の記録。コトの記録を徹底すること。
- イベントソーシング → アプリケーションの状態に対するすべての変化を一連のイベントで表現する設計手法
- 厳密な即時性が必要だし、整合性担保が難しい。機能要件を満たしても非機能要件を満たしづらい
ドメインオブジェクトの設計に、データベースの設計の知識や都合を持ち込んではいけない。ドメインオブジェクトは、業務の関心事を記録する手段。
7章 画面とドメインオブジェクトの設計を連動させる
- 画面に引きずられた設計はソフトウェアの変更を大変にする
- 例: 画面上に特定条件でモーダル出すときに、愚直に追加する
- 上記は関心事を分けて設計すること
- コンポーネント毎に設計する
- タスクベースのインターフェースにする
- 例: topページで複数処理を行うのなら、それぞれgql等でcallしてあげて処理をわける
- 画面項目とドメインオブジェクトは利用者の関心事に一致させること
8章 アプリケーションの間の連携
WepAPIの説明が大半
- One Size Fit APIを避ける (OSFA)
- 肥大化したAPIのこと
- APIは小さく作ろう
- 肥大化したAPIのこと
- 参照と登録を一つのAPIでやるな
9章 オブジェクト指向の開発プロセス
- 多くのドキュメントは不要になる
- 設計と実装者が同じ場合に限るが
- 全体を俯瞰するドキュメントは必要
- 機能要件と非機能要件
10章 オブジェクト指向設計の学び方と教え方
オブジェクト指向をどうやって学ぶか
- 既存コードを改善しながら
- 不吉な臭いを感じ取りながら
- 極端なコーディング規則を守る
オブジェクト指向エクササイズを意識する
全体の感想
- 1章 → ドメイン駆動設計大事。コレクションオブジェクトや完全コンストラクタ意識。
- 2章 → 多態ってポリモーフィズムのことか
- 3章 → メソッドを短く書く。SRPを意識して、クラス分割できないか考えるのは脳死でできるようにしたいね
- 5章 → サービスクラスの知見もっと増やしたい。Rails×DDDは避けるべきやなぁ
- 6章 → FK制約を必須としているが、そのテーブルがログとかならノイズになるから外部キー制約は不要だと思った
- 7章 → とにかく、何でも画面はだめ。画面とドメインオブジェクトの項目の一致を心がける設計にすべし
