何がDDDをDDDにするのか / what make DDD to DDD ?

DDDを学習・実践において多く見受けられる混乱と、それに対する現時点での自分の回答

Transcript

1. 何が“DDD”を”DDD”にするのか 2020/01/18 学生と社会人のライトニングトーク大会 #北海道LT大会 @Philomagi 1
2. 発表者 @Philomagi • 主にフロントエンド主体のWEB系エンジニア • ScalaとTypescriptが好き • PHPは中々縁が切れない悪友 ◦ 最近は、「然程悪いやつでもないな」と思い始めてる 2
3. 概要 • ドメイン駆動設計(DDD) • DDDを取り巻く混乱 • “DDD”を”DDD”足らしめるモノ • まとめ 3
4. ドメイン駆動設計 Domain-Driven Design(DDD) 4
5. ドメイン駆動設計 5
6. DDD is 何？ 6 • ソフトウェア設計の方法論 • Eric Evansによる提唱 • 「ユーザー要求の問題解決にフォーカスした設計パターン」（日本 語版帯より） • 「ドメイン駆動設計、略してDDDと呼ばれるソフトウェア開発手法 がある。（中略）これをうまく使いこなせば、設計した結果が、その ソフトウェアの動作を明確に表すようになる。」(「実践ドメイン駆動 設計 」p.1)
7. DDDを取り巻く混乱 7
8. DDDを取り巻く混乱 8 • 「Entity」「Value Object」「Service」を使えばDDD? • 「Entity」(略)を使わなかったらDDDではない？ • ドメインモデルを書いたらDDD？ • ドメイン分析したらDDD？
9. DDDを取り巻く混乱 9 • 「Entity」「Value Object」「Service」を使えばDDD? • 「Entity」(略)を使わなかったらDDDではない？ • ドメインモデルを書いたらDDD？ • ドメイン分析したらDDD？
10. DDDとパターン 10 DDDは実装パターン集ではない • 各種パターンは、モデルと実装を紐付けるための 道具でしかない • DDD本のパターンを一切使わないDDDも、原理上 は考え得る
11. DDDとドメイン/ドメインモデル 11 ドメイン/ドメインモデルはDDD固有の概念ではない • ドメイン/ドメインモデルは、DDD以前から存在し、かつDDD 以外でも有効な概念 • ドメイン/ドメインモデルはDDDと他の方法論を区別する基準 にはならない • 故に、ドメイン/ドメインモデルを考えればDDDになるのでも ない
12. 何が”DDD”なのか？ 12 「DDDって何をどうすればDDDなの？」 「自分たちのやり方はDDDなの？」
13. 脱線：ドメイン・DDD・「コスト」 13 • ドメイン = 問題領域。ソフトウェアで解決したい問題。 • ドメインの分析と理解は、DDDであろうとなかろうと、ソフトウェア 開発にとって一般に重要な課題。 • 「DDDは高コスト」→ そこで言う「コスト」は何か？ • ドメインの分析・理解を指して「コスト」と語るなら、それはDDDでな くても払うべきコスト。 • 「DDDを使わない」は「ドメインの分析・理解を省略する」と同義で はないし、省略の理由にもならない
14. 何が”DDD”を”DDD”足らしめるのか 14
15. 何が”DDD”を”DDD”足らしめるのか 15 換言すれば DDDで外してはいけない核心は何か DDDと他の方法論の決定的な違いは何か
16. 何が”DDD”を”DDD”足らしめるのか 16 ❌ Entity等のパターン ◦ 単なる道具の一種であり、DDDの構成要件でも、DDD固有の概念 でもない ❌ ドメインモデル ◦ DDD固有の概念でなく、DDD以外でも利用可能 ❌ ドメイン分析 ◦ DDD固有の概念でなく、ソフトウェア開発一般で必要かつ重要なプ ロセス
17. 何が”DDD”を”DDD”足らしめるのか このスライドでは • ドメインに基づく概念/実装の単一モデル • 単一モデルを介したドメイン-ソフトウェア間の相互フィード バック の実践によって「DDDが成立する」と考える 17
18. ドメインに基づく概念/実装の単一モデル 18 業務知識 業務フロー ステークホルダー 課題 制約 ドメイン
19. ドメインに基づく概念/実装の単一モデル 19 業務知識 業務フロー ステークホルダー 課題 制約 ドメイン モデル
20. 単一モデルを介したコミュニケーション 20
21. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 21 ドメイン ソフトウェア XにはX’とX’’の他に X’’’があります XはYの他にZ でも必要です X X’’ Y X’
22. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 22 ドメイン ソフトウェア X X’’ Y X’ X’’ Z フィードバックに基 づくモデル更新
23. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 23 ドメイン ソフトウェア X X’’ Y X’ X’’ Z モデル更新に伴う 実装の更新
24. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 24 ドメイン ソフトウェア X X’’ Y X’ X’’ Z Xを具体的にどうする か、YとZでそれぞれ ルール同じ？
25. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 25 ドメイン ソフトウェア X X’’ Y X’ X’’ Z Xルール フィードバックに基 づくモデル更新
26. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 26 ドメイン ソフトウェア X X’’ Y X’ X’’ Z Xルール そうですね、その ルールはZと普段呼 んでいます
27. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 27 ドメイン ソフトウェア X X’’ Y X’ X’’ Z Z フィードバックに基 づくモデル更新
28. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 28 ドメイン ソフトウェア X X’’ Y X’ X’’ Z Z モデル更新に伴う 実装の更新
29. 単一モデルを介したドメイン-ソフトウェア間の相 互フィードバック 29 ソフトウェア ドメイン 単一モデル
30. ドメイン駆動設計(日本語版) p.510より 本書にあるテクニックをすべて採用するプロジェクトなどないだろう。それで も、ドメイン駆動設計を真剣に行っているプロジェクトはすべて、何らかのか たちでそれとわかるようになる。 決定的な特徴は、対象となるドメインを理解し、その理解をソフトウェアにお いて具現化することを重視することにある。 - 「エリック・エヴァンスのドメイン駆動設計」 p.510 30
31. 何が”DDD”を”DDD”足らしめるのか • ドメインに基づく概念/実装の単一モデル • 単一モデルを介したドメイン-ソフトウェア間の相互フィード バック の実践によって、「対象となるドメインを理解し、その理解をソフ トウェアにおいて具現化する」こと。 31
32. まとめ 32
33. 何が”DDD”を”DDD”足らしめるのか • パターンやモデルそのものは、DDDの根幹ではない • “DDD”を”DDD”足らしめるのは ◦ ドメインに基づく単一モデル ◦ 単一モデルを介した相互フィードバック ◦ ↑の実践によるドメインの理解と、その理解が反映された ソフトウェア 33
34. 最後に 34 • 具体的なHowだけでなく、根幹にある思想・理論 = Whyもちゃんと考えてみる。 • Whyを理解してれば、広く応用が効く。　　Howだ けだと、違うケースに対応し難い。 • Whyを考えると、視点・考え方が広がる。
35. 参考にした資料 35 • エリック・エヴァンスのドメイン駆動設計 (Eric Evans) • 実践ドメイン駆動設計 (Vaughn Vernon) • 意訳Domain-Driven Design (@hirodoragon112 さん) ◦ 「単一モデルを介しての相互フィードバック」は、こちら の資料の議論を基としています
36. ご清聴ありがとうございました 36