3章 業務ロジックをわかりやすく整理する
データとロジックを別のクラスに分けることがわかりにくさを生む
業務アプリケーションのコードの見通しが悪くなる原因
- 業務ロジックの整理
- 三層アーキテクチャ
- プレゼンテーション層
- アプリケーション層
- データソース層
- 三層アーキテクチャ
データクラスを使うと同じロジックがあちこちに重複する
データクラスを使うと業務ロジックの見通しが悪くなる
共通機能ライブラリが失敗する理由
業務ロジックをわかりやすく整理する基本のアプローチ
- 基本的な２つの方針
- データとロジックを一体にして業務ロジックを整理する
- 三層のそれぞれの関心事と業務ロジックの分離を徹底する
データとロジックを一体にして業務ロジックを整理する
業務ロジックを重複させないためにどう設計すればよいか
メソッドをロジックの置き場所にする
業務ロジックをデータを持つクラスに移動する
使う側のクラスに業務ロジックを書き始めたら設計を見直す
メソッドを短く書くとロジックの移動がやりやすくなる
メソッドは必ずインスタンス変数を使う
クラスが肥大化したら小さく分ける
パッケージを使ってクラスを整理する
三層の関心事と業務ロジックの分離を徹底する
業務ロジックを小さなオブジェクトに分けて記述する
- ドメインオブジェクト
- 関連する業務データと業務ロジックを１つにまとめたオブジェクト
- 「ドメイン」とは
- 対象領域とか問題領域
業務ロジックの全体を俯瞰して整理する
- クラスの数が増えたら、パッケージに分ける
- パッケージ間の参照関係を含めて整理すると、全体の業務ロジックを整理しやすい
- ドメインモデル
三層＋ドメインモデルで関心事をわかりやすく分離する
- 三層＋ドメインモデル
4章 ドメインモデルの考え方で設計する
ドメインモデルの考え方を理解する
ドメインモデルで設計すると何がよいのか
- ドメインモデルで設計する狙い
- 業務的な判断・加工・計算のロジックを重複なく一元的に記述する
- 業務の関心事とコードを直接対応させ、どこに何が書いてある化わかりやすく整理する
- 業務ルールの変更や追加のときに、変更の影響を狭い範囲に閉じ込める
ドメインモデルの設計は難しいのか
利用者の関心事とプログラミング単位を一致させる
分析クラスと設計クラスを一致させる
業務に使っている用語をクラス名にする
データモデルではなくオブジェクトモデル
ドメインモデルとデータモデルは何が違うのか
なぜドメインモデルだと複雑な業務ロジックを整理しやすいのか
ドメインモデルをどうやって作っていくか
メモ * ボトムアップで変更しながら作る * 重要な、かならず必要なものから * 独立した部品を組み合わせて機能をつくる * ドメインオブジェクトを機能ベースで考えるのはNG
部分を作りながら全体を組み立てていく
全体と部分を行ったり来たりしながら作っていく
重要な部分から作っていく
独立した部品を組み合わせて機能を実現する
ドメインオブジェクトを機能の一部として設計しない
ドメインオブジェクトの見つけ方
重要な関心事や関係性に注目する
業務の関心事を分類してみる
コトに注目すると全体の関係を整理しやすい
コトは業務ルールの宝庫
何でも約束してよいわけではない
期待されるコト、期待されていないコト
業務ルールの記述 ～手続き形とオブジェクト指向の違い
業務の関心事の基本パターンを覚えておく
ドメインモデルで開発してもトランザクションスクリプトになりがち
業務ルールを記述するドメインオブジェクトの基本パターン
- ドメインオブジェクトの基本の設計パターン
- 業務の関心事のパターン
ドメインオブジェクトの設計を段階的に改善する
組み合わせて確認しながら改良する
業務の言葉をコードと一致させると変更が楽になる
業務を学びながらドメインモデルを成長させていく
業務の理解がドメインモデルを洗練させる
業務知識を取捨選択し、重要な関心事に注力して学ぶ
業務知識の暗黙知を引き出す
言葉をキャッチする
重要な言葉を見極めながらそれをドメインモデルに反映していく
形式的な資料はかえって危険
言葉のあいまいさを具体的にする工夫
基本語彙を増やす努力
繰り返しながらしだいに知識を広げていく
改善を続けながらドメインモデルを成長させる
Chapter 5 アプリケーション機能を組み立てる