実施日時：2019/12/4
対象範囲：第4章
参加者：yodai、みずき、くめごん、まぶり、kassyi

第4章　ドメインモデルの考え方で設計する

ドメインモデルの考え方を理解する

・ドメインモデルで設計すると何がよいのか
ドメインモデルは、ドメインオブジェクトを集めて体系的に整理したもの
ドメインモデルは、業務の用語集や説明書であり、用語の関連や作用をパッケージやクラスで表現する手段
・ドメインモデルの設計は難しいのか
難しくしているのは、オブジェクト指向ブログら民具の経験が足りないこと、要件適宜や分析のやり方が分からない場合
・利用者の関心事とプログラミング単位を一致させる
　議論：要求と要件の違いとは？
　　　　要求をもとに考えた結果が要件
ドメインモデルを開発するには、分析と設計が必要
分析とは、利用者の関心と要求を理解するためのものであり、要求の聞き取りなどを行う。
設計とは、分析をもとにプログラムの構造を考える活動である。
パッケージ構成、クラス構成、メソッド構成とそれぞれの名前を決める。
・分析クラスと設計クラスを一致させる
分析クラスと設計クラスを一致させることが重要
分析クラスを作成時には、業務ロジックを考えながらすることも大事
　議論：オブジェクト指向的の分析と設計とは、何をクラスとして設計するのか？
現実的に、要件を定義する人と実装する人が別部隊となっていることが多く、それによって上手くいかない事が多いのではないか？
⇒個人の力量に依存することが多い。
⇒要件と実装のメンバー同士でコミュニケーションが取れていれば、そこまで酷いことにはならない
・業務に使っている用語をクラス名にする
ドメインモデルは、業務の具体的な用語、概念を手掛かりに進める。
設計の基本は、業務用語の単位で業務ロジックを整理すること。
ドメインモデルの失敗に、業務で使っていない抽象的な言葉をクラス名とするものがある。
　議論：「データベースにアクセスする」をクラスをそのまま使ってしまう悪い例がある（データベースは業務で使わない）。
何かのAPIにアクセスとするのでなく、業務で使う用語をクラス名にする。
ユーザープロファイルというクラス名が大きすぎたので、もう少し具体的なクラス名に変えて、もう少し特化した感じにする。
抽象的な名前のクラス名は何も説明していないので、具体的な業務での活動をクラス名にするのが良い。
・データモデルではなくオブジェクトモデル
ドメインモデルとデータモデルは別のものと考えるのが大切
ドメインモデルは、関心の中心が業務ロジックだが、データモデルはデータが中心となる。
ドメインモデルは対象業務をオブジェクトの集合として表現する。
データをロジックが一体となったオブジェクトとして分析してクラス設計に反映する。
・ドメインモデルとデータモデルは何が違うのか
ドメインモデルはデータと業務ロジックをひとまとまりにしてクラス単位で整理したものであり、関心事はデータでない。
データモデルの中心はデータでデータを整理して記録することが中心。
　議論：図4-1は、クラス図なのに何をするのか分からない。
　　　　ふるまいが書かれていない、テーブル設計みたい。
　　　　例えば、注文クラスは何をするのか？
　　　　それを書いたのが図4-2
・なぜドメインモデルだと複雑な業務ロジックを整理しやすいのか
データモデルの設計は手続き型の設計になる。
業務ロジックが重複しがちでプレゼンテーション層にも業務ロジックが書かれがちになる。
ドメインモデルでは、業務ロジックを一つのクラスに集めて一元的に管理できる。
「年齢」と「生年月日」の例では、データモデルは年齢という業務の関心事が消え、生年月日にアクセスする場所ならばどこにも記述される。
ドメインモデルは、「年齢」がまず整理される。
・部分を作りながら全体を組み立てていく
ドメインモデルはデータとロジックをオブジェクトとして一緒に扱う。
データモデルは、データとロジックの分析・設計を別々にする。
〇手続き型のアプローチ
　全体を俯瞰して定義することから開始する。
　段階的に分割して詳細に定義する。
〇オブジェクト指向のアプローチ
　部分に注目して、個々の部品を作って組み合わせて段階的に作っていくボトムアップ型
・全体と部分を行ったり来たりしながら作っていく
ボトムアップ型でも全体を俯瞰して開発する
全体を俯瞰する道具は、パッケージ図と業務フロー図がある。
〇パッケージ図
　パッケージ単位で全体の構造を俯瞰できる
　クラスが増えればパッケージの構成や名前を改善する
　業務の流れに沿った時間軸がオブジェクト間の関係になる。
　最初のパッケージは後のパッケージを知ることがない。
　パッケージ間の参照関係は業務フロー図を参照する。
〇業務フロー図
　業務活動を時間軸に沿って図示したもの。
　パッケージ図の参照関係に誤りがないかを確認する。
・重要な部分から作っていく
全体を俯瞰したら、重要な部分を探してそこから作っていく。
重要な個所が不明なら、重要そうでないものを除外しながら候補を見つけていく。
候補にミスが有っても、手戻りなどは起こることは殆どない。
ドメインモデルは、修正や拡張が楽で安全な方法である。
・独立した部品を組み合わせて機能を実現する
ドメインモデルはドメインオブジェクトという独立性の高い部品の集まりなので、多くの手戻りや広い範囲の修正は起きにくい。
・ドメインオブジェクトを機能の一部として設計しない
機能（処理？）を中心にして機能を分解しながら部品を作ってはいけない。
上位の機能部品と下位の機能部品は切り離せなくなる。
加えて、処理の順番に依存する。
ドメインモデルは、単体で操作確認ができる独立性の高い部品として開発する。
機能の実現でなく、特定の業務データとそのデータを使った業務ロジックを切り出した独立したオブジェクトを作る。