DDD本3章を読んでこのように理解しました

Last updated at 2019-01-20Posted at 2018-12-08

はじめに

エリック・エヴァンスのドメイン駆動設計(2004)の第3章「モデルと実装を結びつける」を読んで自分的に理解したことを書き出す
結構自分の考えと混じってしまってるので、ここに書いてあることイコール本の内容ではないです

自分の理解の足りないところやおかしいところはバシバシ突っ込んでもらいたいです

これまで開発手法として手続き型が使われていたけど、アナリストの洞察が含まれたモデルを開発者がソースコードに落とし込む際にモデルとプログラムの設計に乖離が起こっていたよね

モデル != コードの都合上モデルは保守されず、コードからは設計思想が抜け落ちてしまう...

工数は伸びるけどモデル駆動設計を使えば、アナリストと開発者で同じモデルを作って、それをコードに落とし込むから乖離が少なくてよき

つまり全員が同じモデルを頭の中に描いていて、コードもそのモデルを表している状態になっている場合は機能追加、改修時もモデルに対しての変更を話し合えばいいっていう状況ができて幸せになれるよ

なのでモデル駆動設計おすすめ
って感じかな...?

3章の内容は開発手法の「手続き型」と「モデル駆動設計」についてが主だと思ったので、その内容のみ深掘りします

どういう手順で開発を行っていたのか
チームとして手続き型の開発経験がほぼないので、自分の会社だったらあれかな？っていうコメント追加してみました。逆に分かりづらくなったら

アナリストが分析モデルを作成
自分が所属している組織だとアナリスト == ディレクターが近いかな?
ディレクターが「こんな感じの画面のこんな遷移するとこうなる機能欲しい」をExcelで作っていた記憶
開発者がアナリストに話を聞きながら設計モデルを作成
クラス図、シーケンス図などが該当?
自分が所属している組織だと昔 Wordに「 1.〇〇する 2. 〇〇の場合は△△」みたいなこと書いてあったけどあれかな...?
開発者が実装
リリース後追加修正があるとコードの該当箇所のみを見て改修

成果物として分析モデル、設計モデルができる

分析モデルと設計モデルにずれが生じモデルがメンテされなくなり、初期の設計思想が失われる
- 分析モデルはビジネスドメインを理解するためだけに使うツールのため、ソフトウェアシステムで果たす役割を全く考慮しないので設計モデルとの間にずれが生じる
分析モデルと設計する人が別なので、実装時にアナリストによってモデルに組み込まれた洞察が失われる
- 開発者が分析モデルを設計にうまく落とし込めない
- アナリストが情報の差異があった際に検知できない
改修があった際に設計モデルを保守するのがきつい
- よくある条件分岐やswitch文が増えるような改修が多くなってしまうはずなので、それを言葉で表すことやパターンを網羅するのは現実的ではない

DDD本で紹介されている開発手法

分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデル(ドメインモデル)を探し出す

設計をコードに落とし込むとコードとビジネスドメインに乖離がないので追加修正が発生した際にドメインモデルに対してのイテレーティブな修正を続ける形

成果物としてドメインモデルができる
設計をコードに落とし込むことになるのでドメインモデルはコード上で表す

ドメインモデルが設計を表していることになるので設計思想がメンテされ続ける
モデルの保守はコードで行える
ドメインモデルをアナリスト(ドメインエキスパート)と開発者で作り上げるので、アナリストの考えが失われない
- 顧客が本当に必要だったものにあるアナリストの設計とプログラマのコードの差がないはず...

難易度が高く、設計と実装ともに工数がかかる
- 分析が技術的な配慮から致命的に妥協した貧弱なものになってはいけない
- ドメインに対する考え方を反映しているが、ソフトウェア設計原則をさけたできのわるい設計になってはいけない
モデルを保守し続けないと意味がない
- モデルを考慮しない場当たり的な更新を加えるとモデルから設計を読み取れなくなる
- レビューやチーム内のモデルを保守する意識をもたせる必要あり

モデル駆動設計いいよ～っていう内容でしたがなんでもかんでもに使えよっていう話ではなく、本の文脈としては設計をしっかりやらないといけないようなドメインに対してのおすすめっていう雰囲気でした

なので、自分のコンテキストに合わせて随時判断しましょう