2019借りて読んだので、気になった箇所を簡単にまとめました。型など業務専用の型を作って、長さなどの制限する。完全コンストラクタ(初期化時に値が決まり、以降変更できない。もの)にすると、コードを読む時に値の変化を気にする必要がなくなる。表せるが、それぞれ独自の型を作っておくと誤った代入をコンパイル時に検出できる。ような型を別名で定義するのと比べて、コンパイル時に上記のような型誤りの検出が可能。プロパティを1つだけ持ち、それの操作メソッドを持つ。する操作の結果は、同じ型のコレクションオブジェクトとして返す。節を排除すると、コードの見通しが良くなる。protocol)と区分ごとの専用クラスを組み合わせて、多態(Polymorphism)を実現する。区分オブジェクト:列挙型を使って業務で扱う区分の一覧を宣言する。業務ロジックをわかりやすく整理するドメインモデルに業務データと業務ロジックを集める。ドメインモデルは画面やデータベースの都合から独立させる。ドメインモデルの考え方で設定する業務の関心ごとはヒト/モノ/コトで整理できる。コトの整理を軸にする。ドメインモデル設計のインプットは、業務の言葉の正しい理解。アプリケーション機能を組み立てる業務的な判断、加工、計算の詳細はドメインモデルに集約する。データベース操作はリポジトリクラスに持っていく。サービスクラスは小さく分ける。小さく分ける基本は、まず登録系のサービスと参照系のサービスを分ける。小さく分けたサービスを組み立てる。必要に応じて、基本的なサービスクラスを組み合わせた複合サービスを提供するシナリオクラスを作る。データベースの設計とドメインオブジェクトカラム名は省略形にしない。入れる必要があるカラムが出てきたら、別テーブルに分けるサイン。一意性制約でデータの重複を防ぐ。外部キー制約でテーブル間の関係を明確にする。記録のタイミングが異なるデータはテーブルを分ける(NULLを防ぐ)。使う(訂正の記録を残せる)。データベースの設計変更でカラムを追加する場合は、テーブルを追加して、そこに入れる。元のテーブルがそのまま利用できる。基本は「コト」を記録するテーブルを作る。「コト」によって変化する「状態」などの派生的なでデータは別テーブルに記録する。この方法では厳密な即時性には対応できない。オブジェクトとテーブルは似てくるが、兼用させないで、違うものとして明示的にマッピングする。画面とドメインオブジェクトの設計を連動させるタスクごとに画面を分ける。画面表示ロジックに業務ロジックを書かない。文を使っている場合は、その条件判断をドメインオブジェクトに移動する(特定の条件で赤字で表示、0件の場合の特別表示、など)。識別子を指定しないで登録し、レスポンスで識別子を返す。識別子を指定して登録する。なりがちだが、それだど修正や拡張が難しくなる。分割する(ただし、あまり細かくすると組み合わせるのが大変になる)。提供し、フィードバックを得ながら追加、変更して行く。登録と参照を分ける、リソースの単位を分ける、ことに気をつける。Comment返信をキャンセルする。WPHackr.com。