非エンジニアがDDD
 (ドメイン駆動設計)について説明してみる。
 くまごろー


ドメイン駆動設計(Domain Driven Design) ・Eric Evansという人が提唱した設計思想 ・ドメインモデルをソフトウェア開発の中心にすえる手法 ・他にも色んな駆動設計 　　・テスト駆動設計（TDD） 　　・モデル駆動設計（MDD）

実際どういう設計思想？
 ドメインモデルをソフトウェア開発の中心にすえ、コードやコミュ ニケーションを常にドメインモデルと一体化させながら、ドメイン モデルを反復的に深化させることで、価値の高いアプリケーショ ンを生み出していこうとする考え方。


よくわからないので 　　　　　　　分解してみる。

「ドメイン」
 ・ソフトウェアが対象としている業務領域
 →　ソフトウェア化の対象となるもの
 
 例：会計ソフトであれば、会計処理の部分がドメイン領域ということになる


「ドメインモデル」
 ・ドメインに存在する概念を抽象化したもの。 
 ※概念・・・在庫管理の「倉庫」や「移動」等
 ・ ドメインに存在する本質的な振る舞いは、すべてドメインモデルに属する形でモデリ ングされる
 


これらをかみ砕くと・・・
 ・現実にある業務(ドメイン)を正しく理解して「ドメインモデル」として表現し、ドメインモ デルを元にコードを作成する設計思想
 ・運用と共にモデルを改善・進化させ続けることで現実の業務とコードの一体化を進 め、運用しやすいアプリケーションを作る
 


どんな利点があるのか？
 ・DDDを実践することで、ドメイン知識がそのままコードへ反映される
 ・ドメイン知識とコードが地続きになる
 　→　変化に強いソフトウェアを構築できる
 
 


実際何をやるのか？
 〇　ドメインオブジェクトを見つける
 （１）ドメインエキスパートからのヒアリング・業務用語集の作成
 （２）業務用語を図式化（業務知識を要約し、関係性を明らかにする）
 （３）ドメインを洗い出す
 →　コードに落とし込む
 


疑問１：MDDとDDDは何が違うの？
 ・MDDは「モデル」を元に行なう設計技法
 ・MDDはドメインだけが適用範囲ではない。（UI等、純粋に技術的なものにも適用でき る）
 ※　ただ、DDDはその実現方法の中心にMDDを採用している。
 →　ドメインの複雑さを理解し、ソフトウェアに反映させる最善策はモデルを使うことで あるというスタンス


疑問２：DDDとOOPはセットなの？
 結論：セットではない
 ・DDDでよく用いられるMDDを実現するのに、オブジェクト指向は（プログラミング技法 として）最適
 →　DDD=OOPでないといけないわけではない


DDDを理解する上で重要そうな言葉①
 ＜ドメインエキスパート＞
 ・ドメイン領域に精通した人のこと。（ユーザーになることが多い）
 
 つまり・・・
 　DDDには非エンジニアの協力が欠かせないということ。（これが時にDDD導入の壁 になるらしい）


DDDを理解する上で重要そうな言葉②
 ＜ユビキタス言語＞
 ・エンジニアとドメインエキスパート双方が理解できる共通用語
 →　エンジニアはドメインエキスパートと比べドメイン領域の知識が少ない。そのた め、エンジニア側がエキスパートの話を正しく理解できず、齟齬を生じさせることがあ る。これを解決するために必要
 


参考になったページ
 ・DDD難民に捧げる Domain-Driven Designのエッセンス 第1回　ドメイン駆動設計とは
 ・非エンジニアの方に「DDDって何なの？」と聞かれたときの説明[ドメイン駆動設計] 
 ・業務知識を中心に考える設計手法ドメイン駆動設計の基礎知識
 ・ドメイン駆動設計に2年間関わって学んだこと
 ・ドメイン駆動設計で保守性をあげたリニューアル事例 〜 ショッピングクーポンの設計紹介


ご清聴ありがとうございました