ドメインモデルの考え方を理解する
ドメインモデルとデータモデルにおけるクラスの責務の違い
ドメインモデル
- データをそのまま入出力するのみではない
- データを求められる情報へと計算・判定・加工を行った上で出力する
- そのためのメソッドを持つ
データモデル
- データの保持と入出力のみ行う
- そのためのセッターとゲッターを持つ
ドメインモデルではコードの重複が減る
- ドメインモデルではデータの計算・判定・加工をデータを保持するオブジェクトに任せられるため、そのためのロジックもそこに集約される
- しかし、データモデルでは、計算・判定・加工を他オブジェクトが行うため、ロジックが分散し、その結果重複も発生する。
ドメインモデルをどうやって作っていくか
業務フロー図
- 業務プロセスや処理の流れの表現
- 実際の業務プロセスが正しいかどうか、業務の抜け漏れがないか、システム化範囲を検討するために使われる
- 業務活動を表現するため、「注文する」「出荷を指示する」「支払う」など、具体的な業務活動や処理を示す
- ここでは活動そのものが焦点となり、パッケージ図のようにオブジェクト構造やシステム内部の要素の名前が出てこない場合がある
パッケージ図
- システム内部構造・依存関係の表現
- システム構造や依存関係を整理して理解するために使われる
- システム内の具体的なクラスやオブジェクトのまとまりを示す
業務フロー図からパッケージ図へ
- ドメインモデルを忠実にオブジェクト指向で設計すると、**業務フロー図（業務プロセスの流れ）とパッケージ図（プログラムの構造）**は、最終的に非常によく似た形になってくるのが自然
- ドメインモデルとは、実際の業務をそのままプログラム構造に落とし込んだものである
- オブジェクト指向設計の本質は「現実世界のモデルをプログラムに反映させる」ことであるため、業務の流れが忠実に再現されていれば、プログラムの設計は必然的に業務の流れと似たものになる
- まずは業務フロー図を作成して、大きな流れを整理する
- それを元に徐々に粒度を細かくしていき、見落としていた業務やオブジェクトを発見する
- こうして明確化した詳細な業務を元にパッケージ図を作成し、プログラム設計を行う
ドメインオブジェクトの見つけ方
業務の関心ごとはヒト・モノ・コト
- 業務の関心ごとはヒト・モノ・コトの３つに分類される。
- これらがどのように関連しているかを明らかにすることで適切にドメインモデルを設計することができる。
- コトに注目する
- コトはイベント、事象、段階、フェーズなどに相当するものである。
- コトの上にヒトやモノが存在するので、コトがどのように関係し合っているのかを整理することが全体像を把握する上で重要である。
- モノの差異の重要性
- モノには、予定と実績の間に差異が発生する場合がある。
- 差異は重要なものである
- 差異が問題となり、その時点で特別な対応が必要になる場合がある
- 後々問題が発覚し、その原因を探るために過去の差異が必要になる場合がある
- ドメインモデルにおける判定ロジック
- 手続き型のトランザクションスクリプトでは、判定ロジックが入れ子構造になりがちで、複雑になりやすい
- オブジェクト指向ドメインモデルでは、判定ロジックをドメインオブジェクトとして独立させるため、常にシンプルな構造になる
- 判定ロジックを担うドメインオブジェクトはコトに相当する
業務の関心ごとの基本パターンを覚えておく
ドメインオブジェクトの基本の設計パターン
ドメインオブジェクトは、大まかに４種類に分類することができる
- 値オブジェクト
- コレクションオブジェクト
- 区分オブジェクト
- 列挙型の集合操作
業務の関心ごとのパターン
業務の関心ごとは、主に次の４つのパターンに分類される
- 口座(Account)パターン
- 期日(Date)パターン
- 方針(Policy)パターン
- 状態(State)パターン
業務の理解がドメインモデルを洗練させる
業務知識の暗黙値
ドメインモデルを正確に設計するためには、その業界の暗黙値をも把握する必要がある。
暗黙値とは、専門家がそれまでの経験から感覚的に体得してきた言語化されていない知識のことである。
暗黙値を把握するには、専門家と会話するしかない。
会話の中で登場する違和感や聞き慣れない言葉が暗黙値の発見につながる。
相手の反応を見る
業務の関心ごとを適切にキャッチし、会話の中で適切に扱うことができるようになると、専門家の反応はよくなる。
逆に、反応が悪かったり、怪訝な雰囲気を感じたら、それは業務の関心ごとを適切にキャッチできていないということであ。
もし、そんな雰囲気を感じたら、言葉の使い方や言い回しを変えてみよう。
相手の反応が良くなってきたら、業務の関心ごとの理解が進んでいる証拠だ。
まとめ
開発者が特定の業界向けシステムのドメインモデルを適切に設計するためには、その業界の基礎知識はもちろん、暗黙知をも適切に把握する必要がある。
暗黙知とは、専門家がそれまでの経験から感覚的に体得してきた言語化されていない知識のことである。
これらの把握の具合は、会話をする上での専門家の反応や表情から測ることができる。
相手の反応が悪かったり、怪訝な表情が見えたら、それは業務の関心ごとを適切にキャッチできていないことを示している。
そういった場合は、言葉の使い方や言い回しを変えたり、あやふやな箇所を深掘りしたりすることで理解を深めていくようにする。