「現場で役立つシステム設計の原則」[2017, 増田 享]を読みました．
まとめと感想について記述していきます．
概要・まとめ
全体感
なんで業務アプリケーションがうまく動かないのか，作成したオブジェクトが解決したい対象（ドメイン）を適切に設計できていないから．
わかりやすいソースコード，設計についてオブジェクト指向設計の特徴を生かしながら，具体的に説明してくれる本となっています．
「ドメインオブジェクト」という単語が頻出し，ドメインと機能を関連付けをこないながら内容が進みつつ，ドメイン知識の重要性について教えてくれます．
また，筆者が参考にした書籍の紹介だけでなく，具体的な章も記述してくれています．
まとめ
CHAPTER 1 小さくまとめてわかりやすくする
オブジェクト指向は変更を楽で安全にする方法．
オブジェクトで値やコレクションなどの複雑さを閉じ込めると変更が楽で安全になる．
CHAPTER 2 場合分けのロジックを整理する
区部毎にコードを整理する手法
- コードのかたまりは，メソッドとして抽出して独立させる
- 関連するデータとロジックは，１つのクラスにまとめる
- 早期リターンやガード節を使う
多態を使う
- インターフェース宣言と，区部ごとに異なるクラスのオブジェクトを「同じ型」として扱うしくみ
- 多態を使うと区分ごとに異なる判断・加工・計算のロジックを整理できる
- 変更が楽で安全になる
列挙型を使う
- 多態は，区分の一覧がわかりづらい
- 区分は，クラスの一覧を明示的に記述できる
CHAPTER 3 業務ロジックをわかりやすく整理する
三層の関心事と業務ロジックの分離を徹底することで，同一のロジックの分散を防ぐ．
ドメインオブジェクト
- 関連する業務データと業務ロジックを一つにまとめたオブジェクトのこと
ドメインモデル
- 業務アプリケーションの対象領域（ドメイン）をオブジェクトのモデルとして整理したもの
三層 + ドメインモデル
- プレゼンテーション層
- UI など外部との入出力を受け持つ
- アプリケーション層
- 業務機能のマクロな手順の記述
- データソース層
- データベースとの入出力を受け持つ
- ドメインモデル
CHAPTER 4 ドメインモデルの考え方で設計する
ドメインモデルで設計する狙い
- 業務的な判断・加工・計算のロジックを重複なく一元的に記述する
- 業務の関心事とコードを直接対応させ，どこに何が書いてあるかわかりやすく整理する
- 業務ルールの変更や追加のときに，変更の影響を狭い範囲に閉じ込める
ドメインモデルの設計が難しいパターン
- オブジェクト指向プログラミングの経験が足りない場合
- 要件定義や分析のやり方がわからないとき
利用者の関心事とプログラミング単位を一致させる
- 分析
- 人間のやりたいことを正しく理解する
- 設計
- 人間のやりたいことを動くソフトウェアとして実現する方法を考える
業務を学びながらドメインモデルを成長させていく
- 業務の用語とうまく対応しないクラスは，業務の分析や理解が足りないことを示している．
- 用語の意味やほかの用語との関係を確認しながら，より適切なクラスの候補を探す
- ソースコードで業務の要求仕様を表現することをプログラムの自己文書化と呼ぶ
ドメインモデルを設計するための基本
- 重要そうでない言葉を判断する
- 言葉と言葉の関係性を見つける
CHAPTER 5 アプリケーション機能を組み立てる
ドメインオブジェクトを使って機能を実現する
アプリーケーション層は処理の流れの進行役であり，調整役
サービスクラスの設計では，次の方針を徹底する
- 業務ロジック(判断・加工・計算など)は，サービスクラスに書かずにドメインオブジェクトに任せる
- 画面の複雑さをそのままサービスクラスに持ち込まない，そのためにサービスクラスのメソッドを基本処理単位に分解する
- データベースの入出力の都合からサービスクラスを独立させる．データベースのデータ操作を意識しないように分離し隠蔽する
CHAPTER 6 データベースの設計とドメインオブジェクト
データの整理に失敗しているデータベース
- どこにどのようなデータが入っているか推測しにくい
- データが入っていないカラムが多井
- データが重複していて，どのデータが正しいのかわからない
- １つのカラムがさまざま目的に利用している
- テーブル間の関係がはっきりしない
コトに注目するデータベース設計
- 業務アプリケーションの中核の関心事は「コト」の管理
- 現実に起きたコトの記録
- 将来起きるコトの記録(約束の記録)
オブジェクトはオブジェクトらしく，テーブルはテーブルらしく
業務ロジックはオブジェクトで，事実の記録はテーブルで
- ドメインオブジェクトの設計に，データベース設計の知識や都合を持ち込んではいけない．
- ドメインオブジェクトは，業務の関心事を整理するための手段．
- 業務で扱うデータを判断・加工・計算するための業務ロジックを記述する手段
- 両者を適切に関連づけることが必要
- ドメインオブジェクトはドメインオブジェクトで，テーブルはテーブルで別々に正しく設計する．
- そのようにして両者の関係を，業務の関心事の表現として正しくマッピングすることが大切．
CHAPTER 7 画面とドメインオブジェクトの設計を連携させる
画面に引きずられた設計はソフトウェアの変更を大変にする
- 表示のためのロジックと業務ロジックが混在してしまう
- 複数の画面に同じコードが重複してしまう
- 注文の登録時の確認画面
- 注文一覧画面
- 一覧から遷移する注文詳細画面
- そのために関心事を分けて整理する
- 画面そものが複雑
- 画面の表示ロジックと業務ロジックが分離できない
CHAPTER 8 アプリケーション間の連携
使いにくい Web API
- データを取得するために指定するパラメータが多い
- 取得したデータの項目数が多い
- 登録時に指定しなければいけないデータ項目が多い
使いやすい API
- 小さな API にする
- 小さなな API を組み合わせたり一部を変更することで多様なニーズに対応できる
- マイクロサービスは，アプリケーションの運用環境をクラウド上にかんたんに構築できるようになったことから生まれた仕組み．
CHAPTER 9 オブジェクト指向の開発プロセス
ドメインモデルを中心にしたソフトウェア開発の進め方は業務ロジックに焦点を当てて開発を進める
オブジェクト指向の変更容易性を実現する開発の２つの焦点
- ドメインモデルに業務ロジックを集めて整理する活動
- 要求の分析とソフトウェアの設計は同じ人間・チームが担当する体制
オブジェクト指向らしい開発の進め方
- ドキュメントの位置付け
- ソースコードを第一級のドキュメントとして活用する
- 開発マネジメントのやり方
- 見積もりと契約
- 進捗や品質の管理
- 要員と体制
技術者以外との情報をとるためのドキュメント
- 利用者向けのドキュメント
- 画面や記帳
- データベースのテーブル名・カラム名とコメント
オブジェクト指向の分析と設計
- 分析工程と設計工程を分割しない
- 分析と設計を同じ人間が担当する
- 自己文書化
- 分析設計の成果はコードで表現する
- ソースコードを中心に進捗と品質をマネジメントする
CHAPTER 10 オブジェクト指向の開発プロセス
オブジェクト指向をどうやって学ぶか
- 既存のコードを改善しながらオブジェクト指向設計を学ぶ
- やや極端なコーディイング規則を使ってオブジェクト指向らしい設計を体で覚える
既存のコードを改善(リファクタリング)しながらオブジェクト指向設計を学ぶ
- 重複したコード
- 長いメソッド
- 巨大なクラス
- リファクタリングは部分的に少しずつ
オブジェクト指向らしい設計を体で覚えることができる過激なコーディング規則(ThoughtWorks アンソロジーより)
- １つのメソッドにつきインデントは１段階までにすること
- else 句を使用しないこと
- すべてのプリミティブ型と文字列型をラップすること
- 1 行につきドットは１つまでにすること
- 名前を省略しないこと
- すべてのエンティティを小さくすること
- １つのクラスにつきインスタンス変数は２つまでにすること
- ファーストクラスコレクションを使用すること
- getter,setter,プロパティを使用しないこと
エンティティを小さく保つガイドライン(著者より)
| 対象 | ガイドライン |
|---|---|
| メソッドの行数 | 1 行を目標にする １行でもより |
| クラスの行数 | 50 行を目標にする 100 行以上は不可 |
| パッケージのファイル数 | 10 ファイル以内 |
オブジェクト指向の考え方を理解する推薦図書
所感
なぜこの本を購入したのかというと，知人のエンジニアが口を揃えて，この本を称賛したからです．
知人の推薦通り，現場で役立つような内容となっており，設計について完全に初心者でも，具体的な説明で設計に何が必要なのかを理解できます．
内容が徐々にドメイン駆動設計に近づいていくので，「ドメイン駆動設計に興味があるけど，そもそも良い設計が何なのか知らない」みたいな人に特におすすめできる本だと思いました．
著者が Java の知見が深いのか，使用歴が長いのかわかりませんが，コードを用いた説明は Java ベースで書かれていました．
要所で Java のフレームワークについて述べているので，周辺知識を持っていると一層理解できると思います．
ただし，思考が Java に傾きすぎてしまうので，現在 Web アプリのバックエンドでよく使われる言語(Go，node.js，Kotlin など)で，書いてくれるともっとわかりやすいのにと思ってしまいました．（ただ一般的に，そのような書籍はあまり見当たらないので望みすぎかもしれません．）
あと，個人開発の範疇だと，設計を意識しなくても，実装できたり，拡張や運用保守などもできてしまうので，ある程度の大規模開発や実務による苦労した経験が必要に感じました，
「リーダブルコード」，「オブジェクト指向でなぜつくるのか」，「ドメイン駆動設計」を足して３で割ったような内容となっており，具体的な説明からとてもわかりやすい良書だと思います．
「クリーンアーキテクチャ」や「ドメイン駆動設計」などにも興味を持てるようになったので読んでみたいと思います．
