モデル駆動設計
前章までで、ドメインの専門家とシステムの専門家によって、ドメインモデルとユビキタス言語が作られてきた。
次には、ソフトウェア開発者によって、ドメインモデルをコードに落としこんでいく。
しかし往々にしてドメインモデルをそのままコードで表現することは出来ず、その問題を解決するためにソフトウェア開発者による恣意的な実装が行われるようになり、最終的な実装とドメインモデルとは乖離してしまうものだ。
それが一概に悪いとは言えない。
問題とすべきなのは、それが性能テストに耐えられるか、拡張性があるか、保守性を持っているかだ。
分析モデル
アナリストが業務ドメインから独自にモデルを作成する手法。
メリット
- ドメインの知識がある程度確立できる
- よく分析された正確なモデルが出来る
デメリット
- 実装を考慮していないため、ソフトウェア開発者はこれを元にさらに別のモデルを作成する必要がある（そしてその後分析モデルは捨てられ忘れられる）。
- アナリストが重要な細部を見落としている可能性がある
- アナリストだけで作成したモデルをソフトウェア開発者に受け渡すような作業フローだと、受け渡し時点で、モデルに記載の無いドメインに関する知識のヌケモレや、曖昧な表記による誤解を招く可能性がある。
所感：「オススメ出来る手法」と書いてある割にはボロクソ言われている。
わーわーモデル（勝手に名前をつけました）
「分析モデル」のデメリットを補完するための手法。
分析モデルとの違い
- ドメインの専門家、アナリスト、ソフトウェア開発者がみんなで集まってモデルを作る（全員がモデルの変更に責任を持つ）
- 出来る限り誤解を無くすため、ユビキタス言語を使う
- モデルとコードとの乖離を無くすため、OOPに基づいた言語で実装する（手続き型はクソ）
所感：なんかめっちゃ手間かかりそう。
モデル駆動設計の基礎要素
レイヤアーキテクチャ
以下のレイヤーに分けて実装しましょう。
- UIレイヤ（いわゆるView）
- アプリケーションレイヤ（ビジネス以外のロジック・オブジェクト）
- ドメインレイヤ（ビジネスロジック・ビジネスオブジェクト）
- インフラストラクチャレイヤ（DBとかファイルとか？）
所感：実例が欲しいナリ
エンティティ
一意な参照性のあるオブジェクト。
例）Rails の ActiveRecord でユニーク制約のあるテーブルから1レコード分を取得し、そのインスタンスとなっているオブジェクト等。
取り扱うオブジェクトがエンティティかエンティティでないか、それが問題だ。
バリューオブジェクト
一意にする必要のないオブジェクト。
なんでもかでもエンティティとして取り扱うのは、考える分には楽だが実行には一意性を確保するためのパフォーマンスコストがかかる。
バリューオブジェクトはその反面、好きなときに作って好きなときに破棄出来る。
このようなオブジェクトは再利用することが出来るが、その場合は単純に作成・削除で管理すべきであり、データを変更出来ないようにすべきだ。
また、バリューオブジェクトの持つデータは分散させずグルーピングすべきだ。