「ドメイン」駆動で考える「ドメイン駆動設計」/consideration of domain-driven design via domain

人と「ドメイン」がいかにして関わるのか、その関わり方を前提に、いかにして「ドメイン」をソフトウェアをという形で実現するのか。
そのための方法論を記述したものとして、「ドメイン駆動設計」を改めて再解釈・再理解してみる試み。

Transcript

1. 「ドメイン」駆動で考える 「ドメイン駆動設計」 〜「ドメイン」と人はどう関わるのか〜 1 @Philomagi 2020/04/20@DDD Talk MeetUp Online #0 #dddcj
2. 発表者 @Philomagi • WEB系プログラマ ◦ ちょっと前までクライアントサイド主体 ◦ 最近はサーバーサイドメインになってきた • ScalaとTypescriptとRubyが好き ◦ Rubyは最近、公私共に若干疎遠 • PHPは中々縁が切れない悪友 ◦ 最近は、「然程悪いやつでもないな」と思い始めてる 2
3. 今回のテーマ 3 • 「ドメイン駆動設計」という方法論を「ドメインを巡って行われ る、人の活動」という視点から捉え直す • 中核であるはずの「ドメイン」について、それはそもそもどう いった性質を持ち、人は「ドメイン」とどのように関わり合うの かを考える • 「ドメイン駆動設計」は「ドメイン」を対象とした知的活動の実 践である
4. 今回のテーマ 4 • 「ドメイン駆動設計」という方法論を「ドメインを巡って行われ る、人の活動」という視点から捉え直す • 中核であるはずの「ドメイン」について、それはそもそもどう いった性質を持ち、人は「ドメイン」とどのように関わり合うの かを考える • 「ドメイン駆動設計」は「ドメイン」を対象とした知的活動の実 践である
5. 今回のテーマ 5 • 「ドメイン駆動設計」という方法論を「ドメインを巡って行われ る、人の活動」という視点から捉え直す • 中核であるはずの「ドメイン」について、それはそもそもどう いった性質を持ち、人は「ドメイン」とどのように関わり合うの かを考える • こうした再認識に基づいて「ドメイン駆動設計 is ...」と「ドメイ ン駆動設計を始めるために」を記述する
6. Eric Evansの 「ドメイン駆動設計」is... 6
7. ドメイン駆動設計の定義 Eric Evans — Tackling Complexity in the Heart of Software(0:56~) • （「エヴァンスの言うDomain-Driven Designとは、要す るに何か？」とよく尋ねられることについて）定義する のは難しい • 一方で、ドメイン駆動設計のポイントあるいは原理に ついては、いくつか注目すべき事項は挙げてある （Youtube自動翻訳からの意訳、（）内は発表者による） 7
8. ドメイン駆動設計は未完成 InfoQ 「Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた」 Evans氏はDDDの定義について問われることが多く、どこまでDDDを堅く定義す べきか思案するに至った。 一極端には、「仔細のない聞こえのよいアドバイス」があるが、実際には「安っぽ い感動を得る」だけだ。 もう一極端には、つまらない「クックブック」があるが、高次の概念を扱うこととは 無縁になりうる代わりに、厳格に従わなければならない。 （中略） DDDが現実の問題のものであるためには、変革と進化を念頭に置く必要があ る。 8
9. 「ドメイン駆動設計 is X」の不在 9 • そもそも「ドメイン駆動設計」の「厳密な定義」なるものは Evans自身も模索中 • Evans自身も懸念している通り、過剰な定義はドメイン駆動 設計を有る種の「マニュアル」「手順書」に貶めてしまう。 ◦ ガイダンスが非常に厳格であると、ほんの些細な変化ですら「あなたは DDDをやっていない」と言われてしまう。 (InfoQの記事より)
10. 「人」と「ドメイン」 10
11. 「ドメイン」に対するEvansの定義 11 すべてのソフトウェアプログラムは、それを使用する ユーザの何らかの活動や関心と関係がある。ユーザ がプログラムを適用するこの対象領域が、ソフトウェア のドメインである。 -「エリック・エヴァンスのドメイン駆動設計」p.2
12. 「ドメイン」の非客観性 12 この定義によれば、「ドメイン」の内容・性質を決定づけ るのは、そこに関わる人々の関心であり、活動であ る。
13. 「ドメイン」の非客観性 13 この定義によれば、「ドメイン」の内容・性質を決定づけ るのは、そこに関わる人々の関心であり、活動であ る。 すなわち人々の「（私は）〜をしたい」「（私は）〜であり たい」という、有る種の主観に「ドメイン」は依存してい る。
14. 「人」が先、「ドメイン」が後 14 ECサイト運営 ECサイト運営業務が発生
15. 「人」が先、「ドメイン」が後 15 ECサイト運営 「ECサイト運営業務のために 必要なことは・・・」
16. 「人」が先、「ドメイン」が後 16 ECサイト運営
17. 「人」が先、「ドメイン」が後 17 ECサイト運営 「特定の商品をセール価格で販 売したい」
18. 「人」が先、「ドメイン」が後 18 ECサイト運営 ECサイト運営 「ECサイト運営業務」が発生
19. 「人」が先、「ドメイン」が後 19 ECサイト運営 ECサイト運営
20. 「人」がもたらす「ドメイン」の多様性 20 ドメインは有る種の主観に依存している。 それは、 同じ「ECサイト運営」と呼ばれる業務であって も、その「ドメイン」はその実際の業務に携わる人々の 関心や活動によって規定されるはず。
21. 「人」がもたらす「ドメイン」の多様性 21 ドメインは有る種の主観に依存している。 それは、 同じ「ECサイト運営」と呼ばれる業務であって も、その「ドメイン」はその実際の業務に携わる人々の 関心や活動によって規定されるはず。
22. 「人」がもたらす「ECサイト運営」の多様性 22 「特定の商品を買ったら特典を 配布したい」 ECサイト運営
23. 「人」がもたらす「ECサイト運営」の多様性 23 「販売開始前の商品を予約で きるようにしたい」 ECサイト運営 「特定の商品を買ったら特典を 配布したい」
24. 「人」がもたらす「ECサイト運営」の多様性 24 「販売開始前の商品を予約で きるようにしたい」 ECサイト運営 「特定の商品を買ったら特典を 配布したい」
25. 「人」がもたらす「ECサイト運営」の多様性 25 「販売開始前の商品を予約で きるようにしたい」 ECサイト運営 「特定の商品を買ったら特典を 配布したい」 同じ名前の業務（ECサイト運営）であっても 両者の「ドメイン」が一致する保証は無い （決して一致しないとも限らないものの）
26. 「人」がもたらす「ECサイト運営」の多様性 26 「特定の商品を買ったら特典を 配布したい」 ECサイト運営-A
27. 「人」がもたらす「ECサイト運営」の多様性 27 「販売開始前の商品を予約で きるようにしたい」 ECサイト運営-B 「特定の商品を買ったら特典を 配布したい」 ECサイト運営-A
28. 「人」がもたらす「ECサイト運営」の多様性 28 「販売開始前の商品を予約で きるようにしたい」 ECサイト運営-B 「特定の商品を買ったら特典を 配布したい」 ECサイト運営-A ユーザーの関心・活動が異なるなら 「ドメイン」も異なる ＝実現すべき領域・対象も異なる
29. 「ドメイン」を知るということ 29 業務の対象（EC運営、在庫、会計 etc...）が同じでも、 そこに携わる人々の関心・活動によって、「ドメイン」の 内容は変わる。 「ドメイン」を知るということは、まさにそこにいる人々が どのような営み・あり方を求め目指しているかというこ と。
30. 「ドメイン」を知るということ 30 業務の対象（EC運営、在庫、会計 etc...）が同じでも、 そこに携わる人々の関心・活動によって、「ドメイン」の 内容は変わる。 「ドメイン」を知るということは、まさにそこにいる人々が どのような営み・あり方を求め目指しているかというこ と。
31. 「ドメイン」と業務知識 31 今まで多くの人々が営んできた活動には、ある程度の 類型を見出すことができる。 業務知識はその類型の一つであり、「ドメイン≠業務知 識」ではあるが、業務知識は個別具体的な「ドメイン」 を理解することを助けてくれる。
32. 「ドメイン」と業務知識 32 今まで多くの人々が営んできた活動には、ある程度の 類型を見出すことができる。 業務知識はその類型の一つであり、「ドメイン≠業務知 識」ではあるが、業務知識は個別具体的な「ドメイン」 を理解することを助けてくれる。
33. 「ドメイン」を知る 33
34. いかに「ドメイン」を知るか 34 「ドメイン」はユーザーの関心・活動によって決定づけ られる以上、ユーザーを通じてしか知り得ない。 そのため、開発者はユーザーとの対話が必要になる。
35. ユーザーを通じて「ドメイン」を知る 35 「Xをする時は、AとBをしてくだ さい」 「Yの時、Aはできちゃいけない んですよね」 「Yの時は、Xはできません」
36. 「知る」ことの二つの側面 36 あるものを「知っている」とは • その対象を知っている（knowing what） • その方法を知っている（knowing how） の両方を備えていることを意味する(Polanyi p.22) 「ドメイン」を「知る」上でも、同様の事が言える。
37. 「ドメイン」を「知る」ための二側面 37 「Yの時は、Xはできません」
38. 「ドメイン」を「知る」ための二側面 38 「Yの時は、Xはできません」 ある「ドメイン」における対象
39. 「ドメイン」を「知る」ための二側面 39 「Yの時は、Xはできません」 ある「ドメイン」における対象 ある「ドメイン」における方法
40. 「ドメイン」を「知る」ためには • 「ドメイン」内の個々の言葉・単語（what） • 上記の要素同士の作用・関連（how） の両方を知る必要がある。 「ドメイン」を「知る」ということ 40
41. 「ドメイン」を「知る」ためには • 「ドメイン」内の個々の言葉・単語（what） • 上記の要素同士の作用・関連（how） の両方を知る必要がある。個別の単語や表現だけ取り出 して覚えても、そこには「ドメイン」としての構造（＝制約・ ルール・知識）は残っていない。 「ドメイン」を「知る」ということ 41
42. 「ドメイン」を表現する 42
43. 「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実 になったといえる。 表現としての「ドメインモデル」 43
44. 「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実 になったといえる。 一方で、ソフトウェアは表現方法としてはあまりに専門的で、そ の内容が正しく「ドメイン」を表現しているか判断が難しい 表現としての「ドメインモデル」 44
45. 「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実 になったといえる。 一方で、ソフトウェアは表現方法としてはあまりに専門的で、そ の内容が正しく「ドメイン」を表現しているか判断が難しい →「ドメインモデル」という表現を挟み、検証可能にする 表現としての「ドメインモデル」 45
46. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 46 ドメイン
47. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 47 ？ ！ or ？ ドメイン
48. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 48 ？ ！ or ？ ドメイン ソフトウェアがどの程度「ドメイン」を 正確に表現しているか、理解が難しい
49. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 49 ドメインモデル ドメイン
50. 「ドメインを 共有可能な形で表現する」 という制約 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 50 ドメインモデル ドメイン
51. 「ドメインを 共有可能な形で表現する」 という制約 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 51 ドメインモデル ドメイン 制約を満たし続けるために ユーザーと開発者の協調（コ ラボレーション）が必要になる
52. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 52 ドメインモデル ドメイン 「ドメインモデルを通じて会話する」 という制約
53. 「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 53 ドメインモデル ドメイン 「ソフトウェアの実装を ドメインモデルと一致させる」 という制約
54. ドメインモデルと、それを使うことに伴って生じるそれぞれ の制約を通じて、ユーザー/開発者/ソフトウェアの3者は検 証可能な形で結合できる。 「ドメインモデル」を通じての結合 54
55. ドメインモデルと、それを使うことに伴って生じるそれぞれ の制約を通じて、ユーザー/開発者/ソフトウェアの3者は検 証可能な形で結合できる。 ドメインモデルは上記の形での結合を達成するための手 段であり道具であり、ドメインモデルそれ自体は目的でも ゴールでもない 「ドメインモデル」を通じての結合 55
56. 「ドメイン」を深く知る 56
57. 「ドメイン」を表現する時の困難 ドメインモデルを通じてソフトウェアを検証可能にし、そのモ デルに即した形でソフトウェアを記述しようとした時、その 過程でしばしば問題が起こる。 57
58. 「ドメイン」を表現する時の困難 ドメインモデルを通じてソフトウェアを検証可能にし、そのモ デルに即した形でソフトウェアを記述しようとした時、その 過程でしばしば問題が起こる。 複数の制約の衝突や概念の矛盾により、整合性を保ちな がらの記述ができないことがある。 58
59. ユーザーは、開発者に対して言葉にできるよりも実際には多く のことをしばしば知っている（暗黙知）。(Polany p.18) なぜ衝突や矛盾は起きるのか 59
60. 形式化（言語化・モデル化）された知識と、背後の暗黙知 60 「Yの時は、Xはできません」
61. 形式化（言語化・モデル化）された知識と、背後の暗黙知 61 「Yの時は、Xはできません」 形式化された知識
62. 形式化（言語化・モデル化）された知識と、背後の暗黙知 62 「Yの時は、Xはできません」 Y 例外 〜の時だけ 排他 Z A & B 月末 上限 無視 暗黙知 X 次期
63. 形式化（言語化・モデル化）された知識と、背後の暗黙知 63 「Yの時は、Xはできません」 Y 例外 〜の時だけ 排他 Z A & B 月末 上限 無視 X 次期 暗黙知を直接知ることはできず、 形式化された範囲でしか知ることはできない
64. 形式化（言語化・モデル化）された知識と、背後の暗黙知 64 「Yの時は、Xはできません」 Y 例外 〜の時だけ 排他 Z A & B 月末 上限 無視 X 次期 暗黙知を事前に全て 形式化しておくこともできない
65. ユーザーは、開発者に対して言葉にできるよりも実際には多く のことをしばしば知っている（暗黙知）。(Polany p.18) 衝突や矛盾が発生するのは、そうした暗黙知の中から、形式化 された知識と衝突・矛盾するものが発見された時。 なぜ衝突や矛盾は起きるのか 65
66. 暗黙知を形式化することの困難さ 66 • 「りんご」と発音する方法を説明してください ◦ 音量、音程、口の形、舌の位置、喉の筋肉、発声方向、etc… • ボールを投げる方法を説明してください ◦ ボールを支えるための握力、指の位置、指の動き、関節の動き、重 心の移動、etc...
67. ユーザーは、開発者に対して言葉にできるよりも実際には多く のことをしばしば知っている（暗黙知）。(Polany p.18) 衝突や矛盾が発生するのは、そうした暗黙知の中から、形式化 された知識と衝突・矛盾するものが発見された時。 これはユーザーの問題ではなく、私達が「人」である以上避けら れない制約と見るべき。 なぜ衝突や矛盾は起きるのか 67
68. 「ドメイン」と暗黙知 68 私達が人である以上、「ドメイン」において重要な概念を事前に 全て手に入れることはできない。
69. 「ドメイン」と暗黙知 69 私達が人である以上、「ドメイン」において重要な概念を事前に 全て手に入れることはできない。 むしろ、こうした段階的な暗黙知の発見・明示化を経て、徐々に 「ドメイン」が定義され確定されていくもの、段階的に発生してい くものと捉える方が実践的。
70. 「ドメイン」と暗黙知 70 私達が人である以上、「ドメイン」において重要な概念を事前に 全て手に入れることはできない。 むしろ、こうした段階的な暗黙知の発見・明示化を経て、徐々に 「ドメイン」が定義され確定されていくもの、段階的に発生してい くものと捉える方が実践的。 その意味で「ドメイン」は所与ではなく定義されるもの。
71. 「ドメイン」の深化（あるいは段階的発生） 71 ドメインモデル ドメイン 記述 実装
72. 「ドメイン」の深化（あるいは段階的発生） 72 ドメインモデル ドメイン 記述 実装 記述/実装という形式化を通じて 形式化されていなかった 「ドメイン」の知識を発見する
73. 「ドメイン」の深化（あるいは段階的発生） 73 ドメインモデル ドメイン 記述 実装 発見された 「ドメイン」知識
74. 「ドメイン」の深化（あるいは段階的発生） 74 ドメインモデル ドメイン 記述 実装 発見された 「ドメイン」知識 新たに発見された知識を ドメインモデルに組み込み、 記述を更新する
75. 「ドメイン」の深化（あるいは段階的発生） 75 ドメインモデル ドメイン 記述 実装 発見された 「ドメイン」知識
76. 「ドメイン」の深化（あるいは段階的発生） 76 ドメインモデル ドメイン 記述 実装 発見された 「ドメイン」知識 一連の活動を通じて、ユーザー/開発者共に 「ドメイン」に対する知識・理解を深め 「ドメイン」を再定義する
77. 77 一流シェフはお客の要望を完全に満足させる料理が作れる （中略） しかし超一流は違う 客が予想もできない新しい皿を作り上げる ”あなた方が本当に食べたかったものはこれなのだ”……と そして人々は”まさにこれが求めていたものだ！今までどうして 気づかなかったんだ！！”と神業に驚嘆するのよ 将太の寿司2 4巻 28話「一流と超一流」より
78. 「ドメイン」を深く知る 見えている個別具体の知識に固執せず 「私達は本当は何をしたいのか」 「私達は本当はどうありたいのか」 「私達はなぜここにいるのか」 を繰り返し問い続け、更新し続ける 78
79. ユーザーと開発者の全体で 「超一流」になる 79
80. 「ドメイン駆動設計」is... 80
81. 人と「ドメイン」の関係 81 • 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、 主観的であり非自律的である。
82. 人と「ドメイン」の関係 82 • 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、 主観的であり非自律的である。 • 私達は「ドメイン」の知識を予め記述しきることはできない。
83. 人と「ドメイン」の関係 83 • 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、 主観的であり非自律的である。 • 私達は「ドメイン」の知識を予め記述しきることはできない。 • 「ドメイン」を現実に動くソフトウェアにするために、私達は不断に「ドメイ ン」の記述を試み、暗黙だった知識を発見し、発見に基づいて「ドメイ ン」を再定義していく必要がある。
84. 「ドメイン駆動設計」とは 84 • 「人はドメインとどう関わるか、関わることができるか」の一般 的な形式を言語化したもの
85. 「ドメイン駆動設計」とは 85 • 「人はドメインとどう関わるか、関わることができるか」の一般 的な形式を言語化したもの • そうして記述された「人」-「ドメイン」の関係性を前提に、「ドメイ ン」をソフトウェアという形で実現するための方法論
86. 86 この方法なるものを料理の「作り方」とか自動車の操縦の「仕 方」のような一定の結果を保証してくれる一連の「手続き」と考え るとすれば、それは論外である。 方法とは本来、デカルトの解析の方法やヘーゲルの弁証法がそ うであったように、思考のスタイル、研究対象に立ち向かう態度 のことなのである。 木田 元 「現象学」序章 現象学とは何か より
87. 「ドメイン駆動設計」とは 87 • 「人はドメインとどう関わるか、関わることができるか」の一般 的な形式を言語化したもの • そうして記述された「人」-「ドメイン」の関係性を前提に、「ドメイ ン」をソフトウェアという形で実現するための方法論 • ソフトウェアという形で「ドメイン」を実現するため、さしあたって 有力と思われる道具を書き添えたもの
88. Evansが書き添えた道具 88 • ドメインモデル ◦ ユーザー/開発者/ソフトウェアを検証可能な形で結合させる • ユビキタス言語 ◦ 厳密なモデルの記述を支える • 戦術的設計パターン ◦ ソフトウェアという形へ落とし込む方法を提供する ◦ 暗黙知の形式化を助ける • 戦略的設計パターン ◦ 大規模な構造を定義する方法を提供する ◦ 暗黙知の形式化を助ける
89. 「ドメイン駆動設計」を始めるために 89 • 何はなくとも、まずは自分（達）が実現するべき「ドメイン」が何 かを知ること。 • 「ドメイン」を知るためには、単にユーザーの言葉を書き留める のではなく、形式化されていない暗黙知を発見するよう務める ことになる。 • 蓄えた「ドメイン」の知識をどうやって記述するかという段階 で、初めて様々な「道具」が関わってくる。
90. 補足）Eric Evansによる 「ドメイン駆動設計」の原則 90
91. ドメイン駆動のポイント・原理 Eric Evans — Tackling Complexity in the Heart of Software(01:30~) • ドメインの中核となる複雑さと契機に注目せよ • ソフトウェアエキスパートとドメインエキスパートのコラボ レーションの中で、モデルを探索せよ • モデルを明示的に表現するソフトウェアを記述せよ • 限られた文脈で、特定のユビキタス言語を使って発話せよ （Youtube自動翻訳からの意訳） 91
92. コラボレーション 92 Eric Evans — Tackling Complexity in the Heart of Software(2:48~) 私達はその（business people, domain expert と呼ばれる）人に対して「そのビ ジネスを知っているのはあなたなのだから、（あなたが）モデルを提供してくださ い」と言っているわけではありません。 「私達はソフトウェアの責任者だからモデルを開発する」とも言いません。 「うまくやっていくためには、（domain expertとsoftware expertが）一緒にやって いく必要がある」と言っているのです。 （Youtube自動翻訳からの意訳、（）内は発表者による）
93. ユビキタス言語 93 Eric Evans — Tackling Complexity in the Heart of Software(3:52~) ソフトウェアはそのモデルを明示的に反映していなければならず、それがユビキ タス言語に繋がります。（中略） 最終的に、コラボレーション・探索 [exploration] ・プログラミングに至るまで全て の一連の筋道は、ドメインの課題をより正確かつ表現力豊かに語るための言語 （＝ユビキタス言語）の進化を意味します。（中略） 「ユビキタス」とは、（会話やドキュメンテーションも含めた）”どこでも” [everywhere] という意味です。ただし、”システム全体のどこでも” という意味では ありません。ユビキタス言語は限定された文脈の内部にあると言わなくてはなり ません。 （Youtube自動翻訳からの意訳、[]内は自動翻訳の字幕、（）内は発表者による）
94. 参考資料(敬称略) 94 • エリック・エヴァンスのドメイン駆動設計 ◦ Eric Evans（著）今関 剛（監訳）和智 右桂、牧野 祐子（訳） • 暗黙知の次元 ◦ Michael Polanyi（著）高橋 勇夫（訳） • 境界の現象学 ◦ 河野 哲也 • 現象学 ◦ 木田 元 • 新装版 フッサールの現象学 ◦ Dan Zahavi（著） 工藤 和男、中村 拓也 (訳) • Eric Evans — Tackling Complexity in the Heart of Software ◦ https://www.youtube.com/watch?v=dnUFEg68ESM
95. 参考資料(敬称略) 95 • [DDD]ドメイン駆動設計の定義についてEric Evansはなんと言っているのか ◦ by @little_hand_s ◦ https://qiita.com/little_hand_s/items/7288a0b3dd5dfb1a4c35 • Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた ◦ https://www.infoq.com/jp/news/2018/10/ddd-not-done/ • 意訳Domain-Driven Design ◦ by @hirodoragon ◦ https://speakerdeck.com/hirodragon112/yi-yi-domain-driven-design • 将太の寿司2 ◦ 寺沢 大介 • アジャイルサムライ 達人開発者への道 ◦ Jonathan Rasmusson（著）西村 直人、角谷 信太郎（訳）
96. ご清聴ありがとうございました 96