借りて読んだので、気になった箇所を簡単にまとめました。
基本的に Web アプリケーション向けの内容なのですが、随所に他のシステムでも役に立ちそうな Tips が入ってます。
第1章 小さくまとめて分かりやすくする
ValueObject
- 電話番号なら String ではなく TelephoneNumber 型など業務専用の型を作って、長さなどの制限する。
- 完全コンストラクタ（初期化時に値が決まり、以降変更できない。Immutable なもの）にすると、コードを読む時に値の変化を気にする必要がなくなる。
- 金額と数量はどちらも Int で表せるが、それぞれ独自の型を作っておくと誤った代入をコンパイル時に検出できる。
- typedef のような型を別名で定義するのと比べて、コンパイル時に上記のような型誤りの検出が可能。
コレクションオブジェクト
- List や Array のプロパティを１つだけ持ち、それの操作メソッドを持つ。
- immutable にする
- 操作の結果は、同じ型のコレクションオブジェクトとして返す。
第2章 場合分けのロジックを整理する
- 早期リターンを使って if 文の else 節を排除すると、コードの見通しが良くなる。
- インターフェイス宣言（Swift なら protocol）と区分ごとの専用クラスを組み合わせて、多態(Polymorphism)を実現する。
- 区分オブジェクト：列挙型を使って業務で扱う区分の一覧を宣言する。
第3章 業務ロジックをわかりやすく整理する
- ドメインモデルに業務データと業務ロジックを集める。
- ドメインモデルは画面やデータベースの都合から独立させる。
第4章 ドメインモデルの考え方で設定する
- 業務の関心ごとはヒト／モノ／コトで整理できる。
- コトの整理を軸にする。
- ドメインモデル設計のインプットは、業務の言葉の正しい理解。
第5章 アプリケーション機能を組み立てる
- 業務的な判断、加工、計算の詳細はドメインモデルに集約する。
- データベース操作はリポジトリクラスに持っていく。
- サービスクラスは小さく分ける。
- 小さく分ける基本は、まず登録系のサービスと参照系のサービスを分ける。
- 小さく分けたサービスを組み立てる。
- 必要に応じて、基本的なサービスクラスを組み合わせた複合サービスを提供するシナリオクラスを作る。
第6章 データベースの設計とドメインオブジェクト
- カラム名は省略形にしない。
- 全てのカラムに NOT NULL 制約を付ける。
- NULL を入れる必要があるカラムが出てきたら、別テーブルに分けるサイン。
- 一意性制約でデータの重複を防ぐ。
- 外部キー制約でテーブル間の関係を明確にする。
- 記録のタイミングが異なるデータはテーブルを分ける（NULLを防ぐ）。
- UPDATE を使わずに、DELETE, INSERT を使う（訂正の記録を残せる）。
- データベースの設計変更でカラムを追加する場合は、テーブルを追加して、そこに入れる。
- 元のテーブルがそのまま利用できる。
- 追加したカラムに NULL を入れなくて済む。
- 基本は「コト」を記録するテーブルを作る。
- 「コト」によって変化する「状態」などの派生的なでデータは別テーブルに記録する。
- 銀行口座で例えるなら、「コト」は入金、出勤、「状態」は残高。
- ただし、この方法では厳密な即時性には対応できない。
- オブジェクトとテーブルは似てくるが、兼用させないで、違うものとして明示的にマッピングする。
第7章 画面とドメインオブジェクトの設計を連動させる
- タスクごとに画面を分ける。
- 画面表示ロジックに業務ロジックを書かない。
- 画面表示で if 文を使っている場合は、その条件判断をドメインオブジェクトに移動する（特定の条件で赤字で表示、0件の場合の特別表示、など）。
第8章 アプリケーション間の連携
- POST と PUT の違い。POST は識別子を指定しないで登録し、レスポンスで識別子を返す。PUT は識別子を指定して登録する。
- Web API は、修正を繰り返すうちに何でも出来る肥大化した API になりがちだが、それだど修正や拡張が難しくなる。
- 修正や拡張を重視する場合、組み合わせて使用するような適度な大きさの API に分割する（ただし、あまり細かくすると組み合わせるのが大変になる）。
- 初期段階では単純な API だけを提供し、フィードバックを得ながら追加、変更して行く。
- 単純な API は、登録と参照を分ける、リソースの単位を分ける、ことに気をつける。
第9章 オブジェクト指向の開発プロセス
- 更新すべきドキュメント：利用者向けのドキュメント、画面や帳票、データベース仕様
- 個人的にはAPI仕様も加えた方が良いかも
第10章 オブジェクト指向設計の学び方と教え方
- 過激なコーディング規則
- 1つのメソッドにつきインデントは1段階までにすること（good）
- else 句を利用しないこと（good）
- 全てのプリミティブ型と文字列をラップすること
- 1行につきドットは1つまでにすること（too much）
- 名前を省略しないこと（good）
- 全てのエンティティを小さくすること
- 1つのクラスにつきインスタンス変数は2つまでにすること（too much）
- ファーストクラスコレクションを使用すること（good）
- getter、setter、ブロパティを使用しないこと（too much）
- ↑ 「過激」と銘打っているだけあって、さすがにやり過ぎだと思う項目が・・・