現場で役立つシステム設計の原則 の読書メモです。
動機
良いコード／悪いコードで学ぶ設計入門 17章に推薦図書的なコーナーがあって、一番最初に挙がっていたこと、Software Designでたびたび記事を読んでわかりやすかったことがあり、同僚も読みたいとのことだったので、じゃあ一緒に読んでみよう、そんなふうになりました。
期待していることとはじめに
期待
- よくない設計やコードのパターンを知り、本業の開発に活かしたいです。
- 仲間と読むことで、同じ目線を持てればなおいい感じです。
はじめに
- ソースがごちゃごちゃ、ちょっとした修正がめちゃ大変、影響がデカい……
- 常に解決したい問題ですね><
- 共通の話題なので、読書会にはもってこいかも。
- ソースを出発点に、段々と上流工程にいくのかしら…。目次を見ているとそんな感じになっていそうです。
どう読もうか…
- いつも通り、各章ごとにつぶやきメモを残しながら進んでいく…。
- じっくり読むほど時間はない…。
- ものによっては、サンプルをRailsで考えてみたいところです。
- うまいことChatGPTやGeminiに指示できるか…。
- 読書会を使って、ほかのひとの疑問や気づき、体験で幅を広げる…。
- 楽しんで読む、を一番大事に読もうと思います。
各章のメモ
WIP
- 第1章 小さくまとめてわかりやすくする
第2章 場合分けのロジックを整理する
プログラムを複雑にする「場合分け」のコード
区分や種別がコードを複雑にする
判断や処理のロジックをメソッドに独立させる
else句をなくすと条件分岐が単純になる
複文は単文に分ける
区分ごとのロジックを別クラスに分ける
区分ごとのクラスを同じ「型」として扱う
区分ごとのクラスのインスタンスを生成する
Javaの列挙型を使えばもっとかんたん
区分ごとの業務ロジックを区分オブジェクトで分析し整理する
状態の遷移ルールをわかりやすく記述する
第2章のまとめ
第3章 業務ロジックをわかりやすく整理する
データとロジックを別のクラスに分けることがわかりにくさを生む
業務アプリケーションのコードの見通しが悪くなる原因
データクラスを使うと同じロジックがあちこちに重複する
データクラスを使うと業務ロジックの見通しが悪くなる
共通機能ライブラリが失敗する理由
業務ロジックをわかりやすく整理する基本のアプローチ
【COLUMN】 データクラスが広く使われているのはなぜか
データとロジックを一体にして業務ロジックを整理する
業務ロジックを重複させないためにはどう設計すればよいか
メソッドをロジックの置き場所にする
業務ロジックをデータを持つクラスに移動する
使う側のクラスに業務ロジックを書き始めたら設計を見直す
メソッドを短く書くとロジックの移動がやりやすくなる
メソッドは必ずインスタンス変数を使う
クラスが肥大化したら小さく分ける
パッケージを使ってクラスを整理する
三層の関心事と業務ロジックの分離を徹底する
業務ロジックを小さなオブジェクトに分けて記述する
業務ロジックの全体を俯瞰して整理する
三層＋ドメインモデルで関心事をわかりやすく分離する
第3章のまとめ
第4章 ドメインモデルの考え方で設計する
ドメインモデルの考え方を理解する
ドメインモデルで設計すると何がよいのか
ドメインモデルの設計は難しいのか
利用者の関心事とプログラミング単位を一致させる
分析クラスと設計クラスを一致させる
業務に使っている用語をクラス名にする
データモデルではなくオブジェクトモデル
ドメインモデルとデータモデルは何が違うのか
なぜドメインモデルだと複雑な業務ロジックを整理しやすいのか
ドメインモデルをどうやって作っていくか
部分を作りながら全体を組み立てていく
全体と部分を行ったり来たりしながら作っていく
重要な部分から作っていく
独立した部品を組み合わせて機能を実現する
ドメインオブジェクトを機能の一部として設計しない
ドメインオブジェクトの見つけ方
重要な関心事や関係性に注目する
業務の関心事を分類してみる
コトに注目すると全体の関係を整理しやすい
コトは業務ルールの宝庫
何でも約束してよいわけではない
期待されるコト，期待されていないコト
業務ルールの記述 ～手続き型とオブジェクト指向の違い
業務の関心事の基本パターンを覚えておく
ドメインモデルで開発してもトランザクションスクリプトになりがち
業務ルールを記述するドメインオブジェクトの基本パターン
ドメインオブジェクトの設計を段階的に改善する
組み合わせて確認しながら改良する
業務の言葉をコードと一致させると変更が楽になる
業務を学びながらドメインモデルを成長させていく
業務の理解がドメインモデルを洗練させる
業務知識を取捨選択し，重要な関心事に注力して学ぶ
業務知識の暗黙知を引き出す
言葉をキャッチする
重要な言葉を見極めながらそれをドメインモデルに反映していく
形式的な資料はかえって危険
言葉のあいまいさを具体的にする工夫
基本語彙を増やす努力
繰り返しながらしだいに知識を広げていく
改善を続けながらドメインモデルを成長させる
第4章のまとめ
第5章 アプリケーション機能を組み立てる
ドメインオブジェクトを使って機能を実現する
アプリケーション層のクラスの役割
三層＋ドメインモデルの構造をわかりやすく実装する
サービスクラスの設計はごちゃごちゃしやすい
サービスクラスを作りながらドメインモデルを改善する
初期のドメインモデルは力不足
ドメインモデルを育てる
画面の多様な要求を小さく分けて整理する
プレゼンテーション層に影響される複雑さ
小さく分ける
小さく分けたサービスを組み立てる
利用する側と提供する側の合意を明確にする
シナリオクラスの効果
データベースの都合から分離する
データベースの入出力に引っ張られる問題
データベース操作ではなく業務の関心事で考える
実際のデータベース操作とリポジトリを組み合わせる
サービスクラスの記述をデータベース操作の詳細から解放する
第5章のまとめ
第6章 データベースの設計とドメインオブジェクト
テーブル設計が悪いとプログラムの変更が大変になる
データの整理に失敗しているデータベース
用途がわかりにくいカラム
いろいろな用途に使う巨大なテーブル
テーブルの関係がわかりにくい
データベース設計をすっきりさせる
基本的な工夫を丁寧に実践する
NOT NULL制約が導くテーブル設計
一意性制約でデータの重複を防ぐ
外部キー制約でテーブル間の関係を明確にする
コトに注目するデータベース設計
業務アプリケーションの中核の関心事は「コト」の管理
ヒトやモノとの関係を正確に記録するための3つの工夫
参照をわかりやすくする工夫
コトの記録に注力したテーブル設計の問題
状態の参照
UPDATE文は使わない
残高更新は同時でなくてもよい
残高更新は1ヵ所でなくてもよい
派生的な情報を転記して作成する
コトの記録から状態を動的に導出する
オブジェクトの設計とテーブルの設計
オブジェクトとテーブルは似てくる
違うものとして明示的にマッピングする
オブジェクトはオブジェクトらしく，テーブルはテーブルらしく
業務ロジックはオブジェクトで，事実の記録はテーブルで
第6章のまとめ
第7章 画面とドメインオブジェクトの設計を連動させる
画面アプリケーションの開発の難しさ
画面にはさまざまな利用者の関心事が詰め込まれる
画面に引きずられた設計はソフトウェアの変更を大変にする
関心事を分けて整理する
画面の関心事を小さく分けて独立させる
複雑な画面は異なる関心事が混ざっている
小さな単位に分けて考える
画面も分けてしまう
タスクベースのインターフェースが増えている2つの理由
タスクベースに分ける設計が今後の主流
画面とドメインオブジェクトを連動させる
画面もドメインオブジェクトも利用者の関心事のかたまり
ドメインオブジェクトと画面の食い違いは設計改善の手がかり
ドメインオブジェクトに書くべきロジック
HTMLのclass属性をドメインオブジェクトから出力する
画面（視覚表現）とソフトウェア（論理構造）を関係づける
項目の並び順とドメインオブジェクトのフィールドの並び順
画面項目のグルーピング
画面のデザインとソフトウェアの設計を連動させながら洗練させていく
画面以外の利用者向けの情報もソフトウェアと整合させる
第7章のまとめ
第8章 アプリケーション間の連携
アプリケーションとアプリケーションをつなぐ
ほかのアプリケーションとの連携がアプリケーションの価値を高める
アプリケーションを連携する4つのやり方
Web APIのしくみを理解する
HTTP通信を使ったアプリケーション間の連携の4つの約束事
要求の対象を指定する
要求の種類を指定する
エラー時の約束事
良いWeb APIとは何か
使いにくいWeb API ～大は小を兼ねるのか？
アプリケーションを組み立てるための部品を提供する
発展性に富んだAPI開発のやり方
単純なことをかんたんにできるAPIの提供から始める
動かしながら設計を発展させていく
APIを利用する側とAPIを提供する側の共同作業の環境を整える
中核となるAPIのセットを設計する
Web APIのバージョン管理
APIを複合したサービスの提供
ドメインオブジェクトとWeb API
データ形式とドメインオブジェクトを変換する際に起こる不一致
導出結果か生データか
複雑な連携に取り組む
共通部分と個別対応部分を明確にする
APIを進化させる
小さなアプリケーションに分けて組み合わせる
複雑なデータの交換
非同期メッセージングを使ったアプリケーション間連携
第8章のまとめ
第9章 オブジェクト指向の開発プロセス
開発の進め方はオブジェクト指向で変わったのか
開発の基本はV字モデル
短期間で開発し修正と拡張を繰り返すことが重要になった
オブジェクト指向の開発はうまくいっているのか
どちらのやり方でも変更がやっかいなソフトウェアが生まれやすい
ドメインモデルを中心にしたソフトウェア開発の進め方
業務ロジックに焦点を当てて開発を進める
ソースコードを第一級のドキュメントとして活用する
多くのドキュメントは不要になる
重要になる活動
更新すべきドキュメント
全体を俯瞰するドキュメントを作成して共有する
技術方式のドキュメントもソースコードで表現する
非機能要件はテストコードで表現する
分析と設計が一体になった開発のやり方をマネジメントする
見積もりと契約
進捗の判断
品質保証
要員と体制
第9章のまとめ
第10章 オブジェクト指向設計の学び方と教え方
オブジェクト指向を学ぶハードル
オブジェクト指向の説明は意味が不明
なぜオブジェクト指向で設計すると良いのかがわからない
オブジェクト指向をどうやって学ぶか
既存のコードを改善しながらオブジェクト指向設計を学ぶ
実際のコードで設計の違いを知る
重複したコード
長いメソッド
巨大なクラス
リファクタリングは部分的に少しずつ
組み立てやすい部品に改善する
設計は少しずつ改良を続ける
オブジェクト指向らしい設計を体で覚える
古い習慣から抜け出すためのちょっと過激なコーディング規則
オブジェクト指向の考え方を理解する
『実装パターン』
『オブジェクト指向入門』
『ドメイン駆動設計』
第10章のまとめ
読み終わって
(TODO)
ベストセクション
(TODO)
心に残った言葉
(TODO)
そのほか思ったこと
(TODO)
