DDD: ドメイン駆動設計 入門 ～はじめの一歩～

社内でDDD勉強会をした際の資料です。
資料のみだと理解がやや難しい構成ですので、ぜひ動画(↓) とセットでご参照ください。

https://www.youtube.com/watch?v=03lDC8s0S5U

Transcript

1. DDD: ドメイン駆動設計 入門 ～はじめの一歩～ @t2kob1(こばやし)　2021/06/10
2. 今日のゴール • 第1部 ◦ DDDについてふんわりその目的を理解できている • 第2部 ◦ DDDにおけるアーキテクチャについてふんわりその目的を理解できている ◦ クリーンアーキテクチャ(CA)についてふんわりその目的を理解できている ◦ DDDとクリーンアーキテクチャの近くて遠い関係性をふんわり理解できている 2
3. やること・やらないこと やること • DDD の全体像の説明 • CA の全体像の説明 • DDD と CA の関係性の 説明 やらないこと • 細かな実装方法の説明 3
4. 注意点 本資料に含まれている内容は 2021/06/10 時点における著者の一意見であり、 会社等を代表する意見ではありません。 DDD もクリーンアーキテクチャも勉強中の身ですので、 資料に誤りが含まれているかもしれません。 なにか気がついた点などありましたらお声がけください。 4
5. 第1部: DDD への第一歩
6. DDD によくある勘違い 6
7. DDDとは何だろう？ Domain Driven Development 7
8. DDDとは何だろう？ Domain Driven Development ・・ではない！！ 8
9. DDDとは何だろう？ Domain Driven Design 9
10. DDDとは何だろう？ ドメイン　 駆動　　　設計 Domain Driven Design 10
11. DDDとは何だろう？ ドメイン　 駆動　 　設計 Domain Driven Design 11
12. つまり設計論 12
13. たとえ Repository を使おうが Entity を使おうが、 「ドメイン」が「設計」を「駆動」しなかったら・・ 13
14. たとえ Repository を使おうが Entity を使おうが、 「ドメイン」が「設計」を「駆動」しなかったら・・ それは DDD ではない！ 14
15. DDD によくある勘違い Q. Repository, Aggregate, Entity などを 使えば DDD なんだよね？ 15
16. DDD によくある勘違い A. 16
17. DDD によくある勘違い ちがうよ! 17
18. DDD によくある勘違い ちがうよ! それは具体的な実装手法のひとつでしかないよ！ 18
19. DDD によくある勘違い - 正しくは Q.Repository, Aggregate, Entity などを 使えば DDD なんだよね？ A.ちがうよ！ それは具体的な実装手法のひとつでしかないよ！ 19
20. DDD is 設計論 20
21. もう少し具体的に 21
22. DDD: ドメイン駆動設計とは？ 22
23. 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 「みんな」で変化し続けられるようにする。 そのための設計論/方法論。 23
24. 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 「みんな」で変化し続けられる ようにする。 そのための設計論/方法論。 24
25. 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 「みんな」で変化し続けられる ようにする。 そのための 設計論/方法論 。 25
26. 「みんな」で変化し続けられるように するための設計論/方法論 26 ドメイン駆動設計 is
28. もう少し具体的に... の前に。 28
29. そもそも ドメイン とは？ 29
30. ドメイン　 駆動　　　設計 Domain Driven Design 30
31. ドメイン　 駆動　　　設計 Domain Driven Design 31 🤔??
32. ドメインとは、 主に「領域」や「範囲」を表す言葉。 32
33. ドメインとは、 主に「領域」や「範囲」を表す言葉。 33 🤔??
34. 「ドメイン」とは・・・ こばやしの解釈: 「人や物・情報が活動する領域」のこと 実はエヴァンス本にも明確な定義がない、、、ように、見える (小声) 沢山の人が説明しているが、言っていることがみんな微妙～～に違う。 34 参考: ・「人のいとなみ」 @hirodragon さん 　　　　・広い意味で言うと「組織が行う事業やそれを取り巻く世界のこと」 @バーノンさん (IDDD本著者)
35. 「ドメイン」=「人や物・情報が活動する領域」 世界 クラファン 銀行 飲食業 自転車 自動車 宇宙開発 カメラ 35
36. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン 36
37. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン is これ 37
38. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ 38 クラファン ドメイン
39. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン 「クラウドファンディングに関係する 人や物・情報などが活動する領域」 39
40. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン 「クラウドファンディングに関係する 人や物・情報などが活動する領域」 と定める。 40
41. 「ドメイン」=「人や物・情報が活動する領域」 世界 銀行 飲食業 自転車 自動車 宇宙開発 カメラ クラファン ドメイン 「クラウドファンディングに関係する 人や物・情報などが活動する領域」 と定める。 41 　境界線を切ることで、 　「私たちが戦うべき領域」を明らかにする。 　このため狭義の「ドメイン」は、 　システム化の対象となる領域と言われることもある。
43. 改めて もう少し具体的に 43
44. 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 「みんな」で変化し続けられる ようにする。 そのための 設計論/方法論 。 44 を、もう少し具体的に。
45. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • • • • 45
46. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • • • 46
47. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • • 47
48. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • 48
49. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 49
50. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 50 これが DDD の全体像
52. なぜ「そうする」のか？ 52
53. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 53 再掲 何で一緒にやるの？ 何で共通の言葉なの？ 図がコミュニケーションと何故 関係するの？ なんでそんなやり方をするの？ どうやって探すの？
54. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 54 再掲 何で一緒にやるの？ 何で共通の言葉なの？ モデルがコミュニケーションと何 故関係するの？ なんでそんなやり方をするの？ どうやって探すの？ きになることだらけ
55. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 55 再掲
56. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 56 再掲
57. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 57 再掲 どこが価値の源泉となるのかを「みんな」で考える
58. どこが価値の源泉となるのかを「みんな」で考える 世界 クラファンドメイン ドメイン の候補 ドメイン の候補 ドメイン の候補 58
59. 世界 クラファンドメイン プロジェク ト運営ドメ イン プロジェク ト審査ドメ イン 振り込み ドメイン プロジェク ト準備ドメ イン どこが価値の源泉となるのかを「みんな」で考える ドメインはこんな 感じだ！！ 59
60. 世界 クラファンドメイン プロジェク ト運営ドメ イン プロジェク ト審査ドメ イン 振り込み ドメイン プロジェク ト準備ドメ イン どこが価値の源泉となるのかを「みんな」で考える ここが最も大切な 「価値の源泉」 になる領域だ！！ 60
61. どこが価値の源泉となるのかを「みんな」で考える Q.なぜ「価値の源泉」を探すのか？ 61
62. どこが価値の源泉となるのかを「みんな」で考える A. ビジネスにとって最も価値の源泉となる 領域を探してそこに注力したいから。 62
63. どこが価値の源泉となるのかを「みんな」で考える A. ビジネスにとって最も価値の源泉となる 領域を探してそこに注力したいから。 人もお金も時間もすべて有限。 変化の早い世の中でビジネスに成功し競合に勝ち続けるためには、 限られたリソースを有効に使わなくてはならない。 63
64. どこが価値の源泉となるのかを「みんな」で考える Q.なぜ「みんな」で考えるのか？ 64
65. どこが価値の源泉となるのかを「みんな」で考える A.それが「最も速度を生み出す」から 65
66. 66 どこが価値の源泉となるのかを「みんな」で考える • 業務に深く関わるシステムをエンジニアだけで作ることが出来るか？
67. 67 どこが価値の源泉となるのかを「みんな」で考える • 業務に深く関わるシステムをエンジニアだけで作ることが出来るか？ ◦ その業務に特別詳しいエンジニアがいれば出来るかもしれない。 ◦ が、実業務では特例や手作業による別ルートなどがありがち。 ◦ 結局手戻りするか現場と乖離してしまう。
68. 68 どこが価値の源泉となるのかを「みんな」で考える • 業務に深く関わるシステムをエンジニアだけで作ることが出来るか？ ◦ その業務に特別詳しいエンジニアがいれば出来るかもしれない。 ◦ が、実業務では特例や手作業による別ルートなどがありがち。 ◦ 結局手戻りするか現場と乖離してしまう。 ビジネスサイドだけでも、 エンジニアだけでも速度が出せない。 だから、「みんな」で一緒に考える。
69. どこが価値の源泉となるのかを「みんな」で考える Q.なぜ「みんな」で考えるのか？ A.それが「最も速度を生み出す」から 69
70. ちょっと脱線 70
71. 実は READYFOR には 「みんな」で考えることで「速度を生み出す」 そんな実例が身近にあります。 71
72. BPMN 72
73. 73 https://itohiro73.hatenablog.com/entry/2018/01/16/082846 BPMN の例
74. 74 https://itohiro73.hatenablog.com/entry/2018/01/16/082846 BPMN の例 エンジニアがビジネスサイドの人にヒアリングして、 図を作って見てもらって、指摘点を直して・・・ では遅い。一緒に作ったほうが断然早い。
77. GFFT 77
78. 脱線おわり 78
80. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 80 再掲
81. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 81 再掲
82. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 82 再掲 「みんな」に共通の言葉でドメインモデルを作る (イメージ)　 プロジェク ト 支援者 支援 実行者
83. 「みんな」に共通の言葉でドメインモデルを作る Q.何で「ドメインモデル」を作るの？ 83
84. 「みんな」に共通の言葉でドメインモデルを作る A. 業務に特化した概念たちを見つけ出したいから 84
85. 「みんな」に共通の言葉でドメインモデルを作る A. 業務に特化した概念たちを見つけ出したいから 85 ドメインA Project 最初はシンプルで 業務に特化。
86. 「みんな」に共通の言葉でドメインモデルを作る A. 業務に特化した概念たちを見つけ出したいから 86 ドメインA ドメインB ドメインC Project システムが成長するにつれて、シンプル だった概念は、様々な理由によって 何も かもを取り込んで雪だるま式に大きくなっ てしまった。
87. 「みんな」に共通の言葉でドメインモデルを作る A. 業務に特化した概念たちを見つけ出したいから 87 ドメインA ドメインB ドメインC ドメインや文脈に特化した概 念として、それぞれ独立させ て考えれば混ざって絡み合 うことがなくなる。 Project Project Project
88. もう少し具体的に 88
89. そのクラファン用語、本当に同じ？ 資金を調達したい人 キュレーターさん 支援してくれる人 89
90. そのクラファン用語、本当に同じ？ 「実行者」 「実行者」 「プロジェクト」 資金を調達したい人 キュレーターさん 支援してくれる人 90
91. 実は・・・ 資金を調達したい人 キュレーターさん 支援してくれる人 資金を調達するた めに作るもの！ 理由を伝えるよ！ より魅力的になるよう にサポートするよ！ 支援先や返礼品な どが見られるページ だよね！ 91
92. 実は・・・ 資金を調達したい人 キュレーターさん 支援してくれる人 資金を調達するた めに作るもの！ 理由を伝えるよ！ より魅力的になるよう にサポートするよ！ 支援先や返礼品な どが見られるページ だよね！ 92 同じ言葉でも、使われる文脈によって 意味や必要な情報が変わってしまう。
93. 実は・・・ 資金を調達したい人 キュレーターさん 支援してくれる人 資金を調達するた めに作るもの！ 理由を伝えるよ！ より魅力的になるよう にサポートするよ！ 支援先や返礼品な どが見られるページ だよね！ 93 また文脈によっては実際には 使われていない言葉だったりする
94. なのにモデルがひとつ・・？ 94
96. プロジェクト 96
104. モンスター 爆 誕 104
105. 105 project.rb
108. 完 108
109. 完 109
110. ドメインや文脈ごとに「言葉」を特化させる 110 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 「プロジェクト」 こう↑ならないように・・・
111. ドメインや文脈ごとに「言葉」を特化させる 111 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 資金を調 達したい 人 キュレー ターさん 支援してく れる人 「プロジェクト」 「プロジェクト」 同じ言葉であっても、ドメインや文脈が違えば違う概念 。 それをドメインモデルをそれぞれ分離する ことで表す。 同じ言葉が、異なる概念としてそれぞれ成長していく。
112. 「みんな」に共通の言葉でドメインモデルを作る Q.何で「ドメインモデル」を作るの？ A. 業務に特化した概念たちを見つけ出したいから 112
114. 「みんな」に共通の言葉でドメインモデルを作る Q.何で「みんな」に共通の言葉を使うの？ 114
115. 「みんな」に共通の言葉でドメインモデルを作る A. ビジネス上の課題を解決することに 　力を使いたいから 115
116. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 116 α β γ project.title = “Sugoi”
117. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 117 α β γ project.title = “Sugoi” 伝言ゲームしてる 場合じゃない
118. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから ドメインで使われている言葉とプログラムで使う言葉までを何度も翻訳する過程で、 本来言葉が持っていた様々な意味が薄れたり変わってしまう。 いわば、私たちはタチの悪い伝言ゲームに挑んでいる。 世界 ビジネス サイドの 人 エンジニ ア モデル 翻訳 翻訳 翻訳 プログラ ム 翻訳 118
119. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから ならば全員で同じ言葉を使いモデルを囲み育てれば良い 119 世界 ドメインモ デル エンジニ ア プログラ ム ビジネス サイドの 人
120. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 伝言ゲームを避けるには、全員で同じ言葉を使えばよい。 そうすればビジネスの本質ではない「翻訳」に力を割く必要もなくなり、 ビジネス上の課題を解決することに集中できる。 120
121. DDD ではこの「伝言ゲーム」をどう解決する？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 121
122. DDD ではこの「伝言ゲーム」をどう解決する？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 122 ドメインモデルをすべての中心に置き、 業務に関わる概念だけで会話できるようにし、 その概念とコードを1:1で対応させる。
123. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 全員で同じ言葉を使ってドメインモデルを囲み育てる。 世界 ビジネス サイドの 人 ドメインモ デル エンジニ ア プログラ ム 123
124. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 全員で同じ言葉を使ってドメインモデルを囲み育てる。 世界 ビジネス サイドの 人 ドメインモ デル エンジニ ア プログラ ム 124 ここが1:1で繋がっ ているから
125. 「みんな」に共通の言葉でドメインモデルを作る A.ビジネス上の課題を解決することに力を使いたいから 全員で同じ言葉を使ってドメインモデルを囲み育てる。 世界 ビジネス サイドの 人 ドメインモ デル エンジニ ア プログラ ム 125 翻訳無しで会話できる && 一緒に設計できる = 超効率的 ここが1:1で繋がっ ているから
126. 「みんな」に共通の言葉でドメインモデルを作る Q.何で「みんな」に共通の言葉を使うの？ A. ビジネス上の課題を解決することに 　力を使いたいから 126
128. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 128 再掲
129. DDD にまつわる勘違い(再掲) Q.Repository, Aggregate, Entity などを 使えば DDD なんだよね？ A.ちがうよ！それは具体的な実装手法のひとつで しかないよ！ 129
130. DDD にまつわる勘違い(再掲) Q.Repository, Aggregate, Entity などを 使えば DDD なんだよね？ A.ちがうよ！それは具体的な実装手法のひとつで しかないよ！ 130
131. DDD にまつわる勘違い(再掲) A.ちがうよ！それは具体的な実装手法のひとつで しかないよ！ 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 　 131
132. DDD にまつわる勘違い(再掲) A.ちがうよ！それは具体的な実装手法のひとつで しかないよ！ 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 132
133. A.ちがうよ！それは具体的な実装手法のひとつでしか ないよ！ 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository, 疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意！！ 133
134. A.ちがうよ！それは具体的な実装手法のひとつでしか ないよ！ 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository, 疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意！！ 134 が... この辺りの目的や関係性を理解しないまま 実装面だけを導入しようとして失敗してしまうのが DDD 導入失敗の黄金パターン。 DDD の主眼は「ドメイン全体の設計」 にあることに注意！
136. 改めて 136
137. 「ドメイン」が「設計」を「駆動」する とはどういうことか？ 137
138. 138 「ドメイン」が「設計」を「駆動」する その一例
139. 今までの説明を図示化すると... 139
140. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 140
141. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 141 • エンジニアとビジネスサイド の人たちが一緒に、
142. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 142 • エンジニアとビジネスサイド の人たちが一緒に、 • 私たちのビジネスの中で最も価値を生む 全力投球すべき部分 を見つけて、 • 全員に共通の言葉 を使い、そこに含まれる 概念の関係性を分析・図示化 • その図をコミュニケーションから実装まで の全ての中心に置く。 　 プロジェ クト 支援者 支援 実行者
143. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 143 外部環境の変化を 皮切りに
144. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 144 外部環境の変化を 皮切りに 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更 　 プロジェク ト 支援者 支援 実行者 寄付 New!
145. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 145 外部環境の変化を 皮切りに それをプログラムに 反映させる 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
146. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 146 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
147. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 147 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる それがビジネス戦略に まで繋がっていく 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更
148. 「ドメイン」が「設計」を「駆動」する？ 外部 環境 ビジネス 戦略 ドメイン モデル プロ グラム エンジニア ビジネス エキス パート 148 外部環境の変化を 皮切りに それをプログラムに 反映させる プログラムを契機にモ デルを深化させる それがビジネス戦略に まで繋がっていく 生まれた課題を解決でき るよう、ドメインモデルをみ んなで変更 「駆動」の一例
149. 「ドメイン」が「設計」を「駆動」する？ 149 コミュニケーションから実装まですべての中心に ドメインモデルを据えることで、 あらゆる変化や相互作用がドメインモデルに影響を及ぼし 設計が進化/深化されていく。 それがドメインが設計を駆動するということ。
150. 150 まとめ
151. DDD: ドメイン駆動設計とは？ 151
152. 「みんな」で変化し続けられるように するための設計論/方法論 152 ドメイン駆動設計 is
153. DDD は具体的にどんなことをする？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 153 再掲
154. おまけ 154
155. DDD の用語に置き換えると？ ビジネスや環境の変化に合わせ、 素早く繰り返し改善し続けられるようにするために・・・ • エンジニアとビジネスサイドの人たちが一緒に、 • 世界に無数にある人・物・情報・活動などの中から、 私たちのビジネスの中で最も価値を生む全力投球すべき部分を見つけて、 • 全員に共通の言葉を使い、そこに含まれる概念の関係性を分析・図示化し、 • その図をコミュニケーションから実装までの全ての中心に置く。 155 コアドメイン ユビキタス言語 ドメインモデル モデル駆動設計・ 各種実装技法 蒸留・ブレイクスルー・ リファクタリング ドメイン・コンテキスト
156. 156 第1部 完
158. 第2部　DDDとアーキテクチャ 158
159. DDD におけるアーキテクチャとは？ 159
160. DDD にまつわる勘違い(再掲) Q.Repository, Aggregate, Entity などを 使えば DDD なんだよね？ A.ちがうよ！それは具体的な実装手法のひとつで しかないよ！ 160
161. A.ちがうよ！それは具体的な実装手法のひとつでしか ないよ！ 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository, 疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意！！ 161
162. A.ちがうよ！それは具体的な実装手法のひとつでしか ないよ！ 162 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい。 だからこそ、変化し続けられるような実装手段を取る。 それが Value Object や Repository, 疎結合なアーキテクチャ などの正体。 あくまでも DDD の目的を達成するための手段として種々の実装方法がある。 つまり「DDD的(OOP的)な実装方法を適用している」からといって、 それが「DDD である」ことにはならない。要注意！！
163. 163 変化の早い世の中でビジネスに成功し競合に勝ち続けるために、 最速で変化に追従できるよう「みんな」で変化し続けたい 変化し続けられるような実装手段を取る必要がある Value Object や Repository, 疎結合なアーキテクチャ などを使う。 か ら か ら
164. DDDにおけるアーキテクチャは DDDの目的を達成するための手段に過ぎない 164
165. DDDにおけるアーキテクチャは DDDの目的を達成するための手段に過ぎない 165 とはいえ、その目的と重なるようなアーキテクチャもある。 それらが DDD とどう違うかについて紹介していきます。
167. クリーンアーキテクチャとは？ 167 【超短縮版】
168. 168 よく見るクリーンアーキテクチャと言えば？ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html これ。 The Clean Architecture.
169. 169 よく見るクリーンアーキテクチャと言えば？ https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html めちゃめちゃ難解。 おそらくこの図を1発 で理解できる人はごく 一部に限られている。
170. 170 まずは今の図を忘れてください
171. まずは図を置き換えて... 171 こう
172. まずは図を置き換えて... 172
173. 173 The Clean Architecture is 鎖国
174. 174 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』
175. 175 クリーンアーキテクチャis 鎖国 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』 The Clean Architectureにとっての外界とは、 業務ロジックやビジネスルール以外のすべて。 UI、DB、キャッシュ、Web(クラウドサービスな ど)、フレームワークですら、外界。
176. 176 何故、鎖国？
177. 外部の世界から 業務ロジック/ビジネスルール に不要なものを持ち込むから 177
178. 外部の世界から 業務ロジック/ビジネスルール に不要なものを持ち込むから 178
179. こういう言葉、聞いたことありませんか？ • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 179 外界からビジネスルールに不要なものを持ち込む？
180. こういう言葉、聞いたことありませんか？ • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 180 外界からビジネスルールに不要なものを持ち込む？ これらは本来、業務ロジック/ビジネスルールとは全く関係がない。 例えば「プロジェクト」を達成するために必要なルールである、 「期間中に目標金額を達成する」には DB が登場する余地はない筈。
181. こういう言葉、聞いたことありませんか？ • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 181 外界からビジネスルールに不要なものを持ち込む？ こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。
182. こういう言葉、聞いたことありませんか？ • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 182 外界からビジネスルールに不要なものを持ち込む？ こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。 だから、鎖国する
183. こういう言葉、聞いたことありませんか？ • 「DBがこうだから変更できないんだよなあ」 • 「ここを直したいけど ActiveRecord と相性悪いんだよなあ」 • 「外部から取り込む CSV の形式が変わったからロジック総崩れだ」 • 「値が変更されたからモデルを.save()しよう」 183 外界からビジネスルールに不要なものを持ち込む？ こういう言葉が出てくるという事は、私たちの業務ロジックやビジネ スルールの中に、こっそり本質と関係のない外界の何かによる影響が 入り込んでしまっていることを意味する。 そしてそれは少しずつ根を張り絡み合い、変更を困難にしていく。 だから、鎖国する 具体的には、依存の関係性を円の外から内に向けた1方向に制限したり、 Dependency Injection や Repository パターン を採用するなどして疎結合化。 このように国内のドメイン特化のビジネスルールと、外界(画面・DB・ライブラリなど) が 交わらないようにすることで平和を守っている。
184. 184 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』
185. 185 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』 業務ロジックやビジネスルールこそが最も 大切である、という事を示している。
186. 186 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』 業務ロジックやビジネスルールこそが最も 大切である、という事を示している。 繋がった
188. 188 つながる DDD と クリーンアーキテクチャ （でも近くて遠い）
189. 189 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』 業務ロジックやビジネスルールこそが最も 大切である、という事を示している。
190. 業務ロジックやビジネスルールこそが最も 大切である、という事を示している。 190 The Clean Architecture is 鎖国して、出島でのみ外界と貿易することで、 国内をきれいに保つための『方法論』 ドメインモデル 業務ロジックやビジネスルール
191. つながる DDD とクリーンアーキテクチャ 191 DDD は・・・ ドメインモデルをコミュニケーショ ンから実装までのすべての中心に置 き、変化に強くする。 クリーンアーキテクチャは・・・ ドメインモデルを自分たちの世界の 中心において守り、外部からの影響 を廃すことで、変化に強くする。
192. つながる DDD とクリーンアーキテクチャ 192 DDD は・・・ ドメインモデルをコミュニケーショ ンから実装までのすべての中心に置 き、変化に強くする。 クリーンアーキテクチャは・・・ ドメインモデルを自分たちの世界の 中心において守り、外部からの影響 を廃すことで、変化に強くする。 変化に強くするという目的は同じ。 だが、目線が異なる。
193. つながる DDD とクリーンアーキテクチャ 193 DDD は・・・ ドメインモデルをコミュニケーショ ンから実装までのすべての中心に置 き、変化に強くする。 クリーンアーキテクチャは・・・ ドメインモデルを自分たちの世界の 中心において守り、外部からの影響 を廃すことで、変化に強くする。 ドメインだけでなく、そのプロセスなど 関わるもの全てが対象 あくまでも自分のドメインモデルをど う実装するかが主軸
194. まとめ 194
195. • DDD とクリーンアーキテクチャは目的が似ている。 • しかし、そもそも目線が全く異なる。 ◦ DDD がドメインだけでなくプロセスなどまで関心を持つ事に対し、 ◦ クリーンアーキテクチャの興味範囲はあくまでもアーキテクチャレベルでしか無い。 ◦ クリーンアーキテクチャはあくまでも「手段」 である。 • つまり、そもそも比較する/できるものではない。 • クリーンアーキテクチャを採用するだけでは DDD ではないことに注意が必要。 195 まとめ ※ クリーンアーキテクチャと鎖国の話については手前味噌ですが Clean Architecture の勘所は『鎖国』だ。 を参照ください。 

197. 197 第2部 完
198. 198 ご清聴ありがとうございました！