DDD
MODEL-DRIVEN DESIGN (P.47) †
担当: 伊藤 (GLAD!!)
要約 †
Chapter 3: Binding Model and Implementation (P.45) †
- P.45 第1段落〜
- あるプロジェクトでは、壁を覆う巨大なクラス図に圧倒されたけれど、学ぶものは少ししかなく、しかもアプリケーションのコードや設計に何の洞察も与えていなかった。ODB を使っていたから、OR マッピングの必要もなかったのにね。
- ドメインモデルはあったけれど、動作するソフトウェアの開発に役立たない紙の上のモデルに何の意味があるの?
- P.46 第3段落
- 別のプロジェクトは、既存の C++ アプリケーションから Java へのリプレースだったけれど、オブジェクトモデリングなしに切り刻まれたから、汎化や抽象化がされずに、既にあるコードなのに増大してしまった。
- P.46 第4段落
- どちらのプロダクトも機能的ではあったけれど、膨張して、理解困難で、保守できなかった。
- P.46 第5段落
- モデルは、ソフトウェア開発プロジェクトのコンテキストを制限するとしても、多くの多様性と役割を提供してくれる。Domain-Driven Design は、初期の分析だけでなく、設計の基礎となるモデルを要求する。
MODEL-DRIVEN DESIGN (P.47) †
- P.47 挿絵の説明
- 星の位置の計算に使うアストロラーベは空のモデルの機械的な実装だ。
- 文脈
- P.47 第1段落
- コードをモデルに関係づけると、コードに意味が与えられ、モデルも意味のあるものとなる。
- 問題
- P.47 第2段落〜
- ドメインモデルがないプロジェクトでは、前の2つの章で論じた知識の咀嚼やコミュニケーションの利益をほとんど得られない。
- モデルとコードに関係が保守されないと、次第に不適切になって誤解に導いてしまう。
- P.47 第4段落〜
- 多くの設計方法論は、分析モデルという名で、設計とは人もものも異なることを擁護する。分析モデルは、業務ドメインを理解するための道具で、実装の観点を混ぜると泥だらけになってしまうと考えられている。
- 純粋な分析モデルもドメインの理解の最初の一歩は与えてくれるけれど、最終的な発見は設計や実装で明らかになるよね。
- P.48 第5段落
- 設計がドメインモデルに対応づけられないと、モデルにほとんど価値が無いし、ソフトウェアの正しさも疑わしい。
- かと言って、モデルと設計の対応が複雑だと、理解しづらいし、設計が変更されたときに保守できない。
- P.48 第6段落〜
- 「モデル駆動設計 (Model-Driven Design)」では、分析モデルと設計を分けずに、両方の目的を満たす1つのモデルを探求する。
- モデリングと設計のプロセスは1つの反復するループになる。
- 解決方法
- P.49 第5段落
- ドメインモデルを文字通り反映させて、ソフトウェアシステムの各部分を設計しよう。
- モデルを見直して、より自然に実装できるように修正しよう。
- 堅牢な「ユビキタス言語 (Ubiquitous Language)」に加えて、分析と設計の両方の目的を満たす1つのモデルを追求しよう。
- P.49 第6段落
- 設計と責務の割当てで使用された用語でモデルを描き始めよう。
- コードはモデルの1表現になる。よって、コードが変わったらおそらくモデルも変わる。
- P.50 第1段落
- コードをモデルに結びつけるために、モデリングのパラダイムを支援するソフトウェア開発ツールや言語が必要になるだろう。オブジェクト指向言語のような。
- P.50 第2段落〜
- 異なるサブシステムでは異なるモデルになっても良い (第14章参照) が、あるサブシステムではコードから要求分析まで1つのモデルを適用しなければならない。
- 期待される結果
- P.50 第4段落
- 問題を捕え実用的な設計を提供する1つのモデルを開発することは、言うのは易しいが行うのは難しい。
- コードがモデルを表現できるように、設計や実装の技術が効果的に使われなければならない (第II部参照)。
- ソフトウェア開発は、モデルと設計とコードを洗練させる反復プロセスになる (第III部参照)。
担当者のつぶやき †
- ドメインモデルってどの程度の詳細度を想定しているのかな? ソースコードと同じ詳細度だと、細かすぎると思うんだけど...
みんなの突っ込み †
- p48、下から5行目の「a deadly divide opens ・・・ does not feed into the other」っていう件はコンサルとSEが分かり合えない（＝顧客の真の要求を満たせない）原因の一つだと思いました。
それだけに分析と設計を１つに統合する方向性を目指したモデル駆動設計に期待したい -- 池田?
- ドメインモデルってどの程度の詳細度を想定しているのかな? > p49 下から3行目「a change to the code ・・・ the change to the model.」ってあるので、ソースコード並みの詳細度になるんでしょうか？-- 池田?
- p.47-49がホントに重要な所っぽいですね。analysisとdesignを分けることの問題点は、分析モデルが結局実装時には捨てられてしまう点にあると(p.47-48)、ここまではいいとして、モデルとデザインが結びついていたとしても、その結びつきが複雑だったら結局メンテナンスできない、と。「じゃあ、どうやってモデルとデザインを結び付けるんだろうか？」となると、基本的には、「ドメイン−モデル−デザイン」を意図的に関連させながらモデルを（イテレーションの中で）発展させていくということなんでしょうか。深読みしすぎかもしれませんが、p.49の太字箇所、"Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious."-普通に訳せば、「（モデルとデザインの）マッピングを明らかにするために、ソフトウェアシステムの構成要素がドメインモデルを正確に反映するよう設計しよう。」ですが、"UBIQUITOUS LANGUAGE"やこれまでのコミュニケーション論を踏まえて、"very literal way"を「（ユビキタス言語に照らして）一字一句正確に反映するように」と解釈するのもアリでしょうか。 -- 和智?
