目次

第1章　小さくまとめてわかりやすくする

なぜソフトウェアの変更は大変なのか

• ソフトウェアの変更に立ち向かう
• 変更が大変なプログラムの特徴
• 変更するたびに変更が大変になる

プログラムの変更が楽になる書き方

• わかりやすい名前を使う
• 長いメソッドは「段落」に分けて読みやすくする
• 目的ごとに変数を用意する
• メソッドとして独立させる
• 異なるクラスの重複したコードをなくす
• 狭い関心事に特化したクラスにする
• メソッドは短く，クラスは小さく

小さなクラスでわかりやすく安全に

• データとロジック
• 基本データ型の落とし穴
• 値の範囲を制限してプログラムをわかりやすく安全にする
• 「値」を扱うための専用のクラスを作る
• 値オブジェクトは「不変」にする
• 「型」を使ってコードをわかりやすく安全にする

複雑さを閉じ込める

• 配列やコレクションはコードを複雑にする
• コレクション型を扱うコードの整理
• コレクション型を扱うロジックを専用クラスに閉じ込める
• コレクションオブジェクトを安定させる
• コレクションオブジェクトは業務の関心事

第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章のまとめ

• 参考文献一覧
• 索引