前回のふりかえり
- 第2章の主旨
- 気になったこと
- 後半で出てきたモデル駆動設計って何？
第3章 モデルと実装を結びつける
- モデル駆動設計 は、分析と設計で同じモデルを使う(両方の目的に使えるモデルを探す)
- 分析と設計でモデルを分けると、それぞれの作業で得られた洞察を活かせない
モデリングパラダイムとツールによるサポート
- モデルと設計 はお互いが対応してないといけない。一方を変更したらもう一方も変更しないといけない
- モデルを正確にコードへ落とし込むには、それが可能な技術(OOPなど)を用いることが必要
実践的モデラ
- 原則：モデルとコードを分離させない
- モデルとコードが分離すると、モデルが持つ意図をコードに引き継げなくなる
- モデルとコードが分離すると、モデルは実装時のフィードバックを受け取れなくなる
→ モデルは実用的なものではなくなる
必要なこと
- モデル に貢献する人は、 コード にも触れないといけない
- コード を触れる人は、コード を通してモデル表現できるようにならないといけない
- 開発者は、ドメインエキスパートとモデルについて議論する場に参加しないといけない
MDDはモデルと実装を密接に結びつける
気になったこと・思ったこと
- DDDとMDDって結局何がどう違うの？(後述)
ドメインモデル≒ユビキタス言語という図式とモデル≒設計という図式があるのはわかった。この二つの図式を一つの図にするとどのような図になるのかがまだよくわかっていない- 「モデルとコードは一体」という図式に、「構想と実行の分断」という言葉を連想した。
DDDとMDDの違いについて
第3章まで読んでいて、どうしてもドメイン駆動設計とモデル駆動設計の違いがわからなかったが、下記の記事を見つけました。
DDDとは「ドメイン」を最も重視し、それをすべての中心に置く方法です。MDDは「モデル」を元に行なう設計技法を指します。ドメインの複雑さを理解し、ソフトウェアに反映させる最も良い方法はモデルを使うことである（とDDDは仮定する）ために、DDDはその実現方法の中心にMDDを採用します。一方で、MDDは必ずしもドメインだけが適用範囲ではありません。UIやアプリケーションフレームワークなど、純粋に技術的なものにも適用できます。MDDはDDDにとって必須ではないが、ごく自然な伴侶という関係になります。
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
決してDDD=MDDというわけではなく、
- DDDではドメインをソフトウェアに反映させる方法としてモデル駆動設計(モデルを使った設計技法)を推奨している
- MDD自体では、ドメイン以外もモデリングの対象になる。DDDではモデリングの対象をドメインに絞っている。
こういう構図ということかな？
