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

Slide 1

Slide 1 text

「ドメイン」駆動で考える「ドメイン駆動設計」〜「ドメイン」と人はどう関わるのか〜 1 @Philomagi 2020/04/20@DDD Talk MeetUp Online #0 #dddcj

Slide 2

Slide 2 text

発表者 @Philomagi ● WEB系プログラマ ○ ちょっと前までクライアントサイド主体 ○ 最近はサーバーサイドメインになってきた ● ScalaとTypescriptとRubyが好き ○ Rubyは最近、公私共に若干疎遠 ● PHPは中々縁が切れない悪友 ○ 最近は、「然程悪いやつでもないな」と思い始めてる 2

Slide 3

Slide 3 text

今回のテーマ 3 ● 「ドメイン駆動設計」という方法論を「ドメインを巡って行われる、人の活動」という視点から捉え直す ● 中核であるはずの「ドメイン」について、それはそもそもどういった性質を持ち、人は「ドメイン」とどのように関わり合うのかを考える ● 「ドメイン駆動設計」は「ドメイン」を対象とした知的活動の実践である

Slide 4

Slide 4 text

今回のテーマ 4 ● 「ドメイン駆動設計」という方法論を「ドメインを巡って行われる、人の活動」という視点から捉え直す ● 中核であるはずの「ドメイン」について、それはそもそもどういった性質を持ち、人は「ドメイン」とどのように関わり合うのかを考える ● 「ドメイン駆動設計」は「ドメイン」を対象とした知的活動の実践である

Slide 5

Slide 5 text

今回のテーマ 5 ● 「ドメイン駆動設計」という方法論を「ドメインを巡って行われる、人の活動」という視点から捉え直す ● 中核であるはずの「ドメイン」について、それはそもそもどういった性質を持ち、人は「ドメイン」とどのように関わり合うのかを考える ● こうした再認識に基づいて「ドメイン駆動設計 is ...」と「ドメイン駆動設計を始めるために」を記述する

Slide 6

Slide 6 text

Eric Evansの「ドメイン駆動設計」is... 6

Slide 7

Slide 7 text

ドメイン駆動設計の定義 Eric Evans — Tackling Complexity in the Heart of Software(0:56~) ● （「エヴァンスの言うDomain-Driven Designとは、要するに何か？」とよく尋ねられることについて）定義するのは難しい ● 一方で、ドメイン駆動設計のポイントあるいは原理については、いくつか注目すべき事項は挙げてある（Youtube自動翻訳からの意訳、（）内は発表者による） 7

Slide 8

Slide 8 text

ドメイン駆動設計は未完成 InfoQ 「Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた」 Evans氏はDDDの定義について問われることが多く、どこまでDDDを堅く定義すべきか思案するに至った。一極端には、「仔細のない聞こえのよいアドバイス」があるが、実際には「安っぽい感動を得る」だけだ。もう一極端には、つまらない「クックブック」があるが、高次の概念を扱うこととは無縁になりうる代わりに、厳格に従わなければならない。（中略） DDDが現実の問題のものであるためには、変革と進化を念頭に置く必要がある。 8

Slide 9

Slide 9 text

「ドメイン駆動設計 is X」の不在 9 ● そもそも「ドメイン駆動設計」の「厳密な定義」なるものは Evans自身も模索中 ● Evans自身も懸念している通り、過剰な定義はドメイン駆動設計を有る種の「マニュアル」「手順書」に貶めてしまう。 ○ ガイダンスが非常に厳格であると、ほんの些細な変化ですら「あなたは DDDをやっていない」と言われてしまう。 (InfoQの記事より)

Slide 10

Slide 10 text

「人」と「ドメイン」 10

Slide 11

Slide 11 text

「ドメイン」に対するEvansの定義 11 すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用するこの対象領域が、ソフトウェアのドメインである。 -「エリック・エヴァンスのドメイン駆動設計」p.2

Slide 12

Slide 12 text

「ドメイン」の非客観性 12 この定義によれば、「ドメイン」の内容・性質を決定づけるのは、そこに関わる人々の関心であり、活動である。

Slide 13

Slide 13 text

「ドメイン」の非客観性 13 この定義によれば、「ドメイン」の内容・性質を決定づけるのは、そこに関わる人々の関心であり、活動である。すなわち人々の「（私は）〜をしたい」「（私は）〜でありたい」という、有る種の主観に「ドメイン」は依存している。

Slide 14

Slide 14 text

「人」が先、「ドメイン」が後 14 ECサイト運営 ECサイト運営業務が発生

Slide 15

Slide 15 text

「人」が先、「ドメイン」が後 15 ECサイト運営「ECサイト運営業務のために必要なことは・・・」

Slide 16

Slide 16 text

「人」が先、「ドメイン」が後 16 ECサイト運営

Slide 17

Slide 17 text

「人」が先、「ドメイン」が後 17 ECサイト運営「特定の商品をセール価格で販売したい」

Slide 18

Slide 18 text

「人」が先、「ドメイン」が後 18 ECサイト運営 ECサイト運営「ECサイト運営業務」が発生

Slide 19

Slide 19 text

「人」が先、「ドメイン」が後 19 ECサイト運営 ECサイト運営

Slide 20

Slide 20 text

「人」がもたらす「ドメイン」の多様性 20 ドメインは有る種の主観に依存している。それは、同じ「ECサイト運営」と呼ばれる業務であっても、その「ドメイン」はその実際の業務に携わる人々の関心や活動によって規定されるはず。

Slide 21

Slide 21 text

「人」がもたらす「ドメイン」の多様性 21 ドメインは有る種の主観に依存している。それは、同じ「ECサイト運営」と呼ばれる業務であっても、その「ドメイン」はその実際の業務に携わる人々の関心や活動によって規定されるはず。

Slide 22

Slide 22 text

「人」がもたらす「ECサイト運営」の多様性 22 「特定の商品を買ったら特典を配布したい」 ECサイト運営

Slide 23

Slide 23 text

「人」がもたらす「ECサイト運営」の多様性 23 「販売開始前の商品を予約できるようにしたい」 ECサイト運営「特定の商品を買ったら特典を配布したい」

Slide 24

Slide 24 text

「人」がもたらす「ECサイト運営」の多様性 24 「販売開始前の商品を予約できるようにしたい」 ECサイト運営「特定の商品を買ったら特典を配布したい」

Slide 25

Slide 25 text

「人」がもたらす「ECサイト運営」の多様性 25 「販売開始前の商品を予約できるようにしたい」 ECサイト運営「特定の商品を買ったら特典を配布したい」同じ名前の業務（ECサイト運営）であっても両者の「ドメイン」が一致する保証は無い（決して一致しないとも限らないものの）

Slide 26

Slide 26 text

「人」がもたらす「ECサイト運営」の多様性 26 「特定の商品を買ったら特典を配布したい」 ECサイト運営-A

Slide 27

Slide 27 text

「人」がもたらす「ECサイト運営」の多様性 27 「販売開始前の商品を予約できるようにしたい」 ECサイト運営-B 「特定の商品を買ったら特典を配布したい」 ECサイト運営-A

Slide 28

Slide 28 text

「人」がもたらす「ECサイト運営」の多様性 28 「販売開始前の商品を予約できるようにしたい」 ECサイト運営-B 「特定の商品を買ったら特典を配布したい」 ECサイト運営-A ユーザーの関心・活動が異なるなら「ドメイン」も異なる＝実現すべき領域・対象も異なる

Slide 29

Slide 29 text

「ドメイン」を知るということ 29 業務の対象（EC運営、在庫、会計 etc...）が同じでも、そこに携わる人々の関心・活動によって、「ドメイン」の内容は変わる。「ドメイン」を知るということは、まさにそこにいる人々がどのような営み・あり方を求め目指しているかということ。

Slide 30

Slide 30 text

「ドメイン」を知るということ 30 業務の対象（EC運営、在庫、会計 etc...）が同じでも、そこに携わる人々の関心・活動によって、「ドメイン」の内容は変わる。「ドメイン」を知るということは、まさにそこにいる人々がどのような営み・あり方を求め目指しているかということ。

Slide 31

Slide 31 text

「ドメイン」と業務知識 31 今まで多くの人々が営んできた活動には、ある程度の類型を見出すことができる。業務知識はその類型の一つであり、「ドメイン≠業務知識」ではあるが、業務知識は個別具体的な「ドメイン」を理解することを助けてくれる。

Slide 32

Slide 32 text

「ドメイン」と業務知識 32 今まで多くの人々が営んできた活動には、ある程度の類型を見出すことができる。業務知識はその類型の一つであり、「ドメイン≠業務知識」ではあるが、業務知識は個別具体的な「ドメイン」を理解することを助けてくれる。

Slide 33

Slide 33 text

「ドメイン」を知る 33

Slide 34

Slide 34 text

いかに「ドメイン」を知るか 34 「ドメイン」はユーザーの関心・活動によって決定づけられる以上、ユーザーを通じてしか知り得ない。そのため、開発者はユーザーとの対話が必要になる。

Slide 35

Slide 35 text

ユーザーを通じて「ドメイン」を知る 35 「Xをする時は、AとBをしてください」「Yの時、Aはできちゃいけないんですよね」「Yの時は、Xはできません」

Slide 36

Slide 36 text

「知る」ことの二つの側面 36 あるものを「知っている」とは ● その対象を知っている（knowing what） ● その方法を知っている（knowing how）の両方を備えていることを意味する(Polanyi p.22) 「ドメイン」を「知る」上でも、同様の事が言える。

Slide 37

Slide 37 text

「ドメイン」を「知る」ための二側面 37 「Yの時は、Xはできません」

Slide 38

Slide 38 text

「ドメイン」を「知る」ための二側面 38 「Yの時は、Xはできません」ある「ドメイン」における対象

Slide 39

Slide 39 text

「ドメイン」を「知る」ための二側面 39 「Yの時は、Xはできません」ある「ドメイン」における対象ある「ドメイン」における方法

Slide 40

Slide 40 text

「ドメイン」を「知る」ためには ● 「ドメイン」内の個々の言葉・単語（what） ● 上記の要素同士の作用・関連（how）の両方を知る必要がある。「ドメイン」を「知る」ということ 40

Slide 41

Slide 41 text

「ドメイン」を「知る」ためには ● 「ドメイン」内の個々の言葉・単語（what） ● 上記の要素同士の作用・関連（how）の両方を知る必要がある。個別の単語や表現だけ取り出して覚えても、そこには「ドメイン」としての構造（＝制約・ルール・知識）は残っていない。「ドメイン」を「知る」ということ 41

Slide 42

Slide 42 text

「ドメイン」を表現する 42

Slide 43

Slide 43 text

「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実になったといえる。表現としての「ドメインモデル」 43

Slide 44

Slide 44 text

「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実になったといえる。一方で、ソフトウェアは表現方法としてはあまりに専門的で、その内容が正しく「ドメイン」を表現しているか判断が難しい表現としての「ドメインモデル」 44

Slide 45

Slide 45 text

「ドメイン」は、ソフトウェアという方法で表現されて、初めて現実になったといえる。一方で、ソフトウェアは表現方法としてはあまりに専門的で、その内容が正しく「ドメイン」を表現しているか判断が難しい →「ドメインモデル」という表現を挟み、検証可能にする表現としての「ドメインモデル」 45

Slide 46

Slide 46 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 46 ドメイン

Slide 47

Slide 47 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 47 ？！ or ？ドメイン

Slide 48

Slide 48 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 48 ？！ or ？ドメインソフトウェアがどの程度「ドメイン」を正確に表現しているか、理解が難しい

Slide 49

Slide 49 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 49 ドメインモデルドメイン

Slide 50

Slide 50 text

「ドメインを共有可能な形で表現する」という制約「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 50 ドメインモデルドメイン

Slide 51

Slide 51 text

「ドメインを共有可能な形で表現する」という制約「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 51 ドメインモデルドメイン制約を満たし続けるためにユーザーと開発者の協調（コラボレーション）が必要になる

Slide 52

Slide 52 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 52 ドメインモデルドメイン「ドメインモデルを通じて会話する」という制約

Slide 53

Slide 53 text

「ドメイン」/「人」/ソフトウェアの結合点としての「ドメインモデル」 53 ドメインモデルドメイン「ソフトウェアの実装をドメインモデルと一致させる」という制約

Slide 54

Slide 54 text

ドメインモデルと、それを使うことに伴って生じるそれぞれの制約を通じて、ユーザー/開発者/ソフトウェアの3者は検証可能な形で結合できる。「ドメインモデル」を通じての結合 54

Slide 55

Slide 55 text

ドメインモデルと、それを使うことに伴って生じるそれぞれの制約を通じて、ユーザー/開発者/ソフトウェアの3者は検証可能な形で結合できる。ドメインモデルは上記の形での結合を達成するための手段であり道具であり、ドメインモデルそれ自体は目的でもゴールでもない「ドメインモデル」を通じての結合 55

Slide 56

Slide 56 text

「ドメイン」を深く知る 56

Slide 57

Slide 57 text

「ドメイン」を表現する時の困難ドメインモデルを通じてソフトウェアを検証可能にし、そのモデルに即した形でソフトウェアを記述しようとした時、その過程でしばしば問題が起こる。 57

Slide 58

Slide 58 text

「ドメイン」を表現する時の困難ドメインモデルを通じてソフトウェアを検証可能にし、そのモデルに即した形でソフトウェアを記述しようとした時、その過程でしばしば問題が起こる。複数の制約の衝突や概念の矛盾により、整合性を保ちながらの記述ができないことがある。 58

Slide 59

Slide 59 text

ユーザーは、開発者に対して言葉にできるよりも実際には多くのことをしばしば知っている（暗黙知）。(Polany p.18) なぜ衝突や矛盾は起きるのか 59

Slide 60

Slide 60 text

形式化（言語化・モデル化）された知識と、背後の暗黙知 60 「Yの時は、Xはできません」

Slide 61

Slide 61 text

形式化（言語化・モデル化）された知識と、背後の暗黙知 61 「Yの時は、Xはできません」形式化された知識

Slide 62

Slide 62 text

形式化（言語化・モデル化）された知識と、背後の暗黙知 62 「Yの時は、Xはできません」 Y 例外〜の時だけ排他 Z A & B 月末上限無視暗黙知 X 次期

Slide 63

Slide 63 text

形式化（言語化・モデル化）された知識と、背後の暗黙知 63 「Yの時は、Xはできません」 Y 例外〜の時だけ排他 Z A & B 月末上限無視 X 次期暗黙知を直接知ることはできず、形式化された範囲でしか知ることはできない

Slide 64

Slide 64 text

形式化（言語化・モデル化）された知識と、背後の暗黙知 64 「Yの時は、Xはできません」 Y 例外〜の時だけ排他 Z A & B 月末上限無視 X 次期暗黙知を事前に全て形式化しておくこともできない

Slide 65

Slide 65 text

ユーザーは、開発者に対して言葉にできるよりも実際には多くのことをしばしば知っている（暗黙知）。(Polany p.18) 衝突や矛盾が発生するのは、そうした暗黙知の中から、形式化された知識と衝突・矛盾するものが発見された時。なぜ衝突や矛盾は起きるのか 65

Slide 66

Slide 66 text

暗黙知を形式化することの困難さ 66 ● 「りんご」と発音する方法を説明してください ○ 音量、音程、口の形、舌の位置、喉の筋肉、発声方向、etc… ● ボールを投げる方法を説明してください ○ ボールを支えるための握力、指の位置、指の動き、関節の動き、重心の移動、etc...

Slide 67

Slide 67 text

ユーザーは、開発者に対して言葉にできるよりも実際には多くのことをしばしば知っている（暗黙知）。(Polany p.18) 衝突や矛盾が発生するのは、そうした暗黙知の中から、形式化された知識と衝突・矛盾するものが発見された時。これはユーザーの問題ではなく、私達が「人」である以上避けられない制約と見るべき。なぜ衝突や矛盾は起きるのか 67

Slide 68

Slide 68 text

「ドメイン」と暗黙知 68 私達が人である以上、「ドメイン」において重要な概念を事前に全て手に入れることはできない。

Slide 69

Slide 69 text

「ドメイン」と暗黙知 69 私達が人である以上、「ドメイン」において重要な概念を事前に全て手に入れることはできない。むしろ、こうした段階的な暗黙知の発見・明示化を経て、徐々に「ドメイン」が定義され確定されていくもの、段階的に発生していくものと捉える方が実践的。

Slide 70

Slide 70 text

「ドメイン」と暗黙知 70 私達が人である以上、「ドメイン」において重要な概念を事前に全て手に入れることはできない。むしろ、こうした段階的な暗黙知の発見・明示化を経て、徐々に「ドメイン」が定義され確定されていくもの、段階的に発生していくものと捉える方が実践的。その意味で「ドメイン」は所与ではなく定義されるもの。

Slide 71

Slide 71 text

「ドメイン」の深化（あるいは段階的発生） 71 ドメインモデルドメイン記述実装

Slide 72

Slide 72 text

「ドメイン」の深化（あるいは段階的発生） 72 ドメインモデルドメイン記述実装記述/実装という形式化を通じて形式化されていなかった「ドメイン」の知識を発見する

Slide 73

Slide 73 text

「ドメイン」の深化（あるいは段階的発生） 73 ドメインモデルドメイン記述実装発見された「ドメイン」知識

Slide 74

Slide 74 text

「ドメイン」の深化（あるいは段階的発生） 74 ドメインモデルドメイン記述実装発見された「ドメイン」知識新たに発見された知識をドメインモデルに組み込み、記述を更新する

Slide 75

Slide 75 text

「ドメイン」の深化（あるいは段階的発生） 75 ドメインモデルドメイン記述実装発見された「ドメイン」知識

Slide 76

Slide 76 text

「ドメイン」の深化（あるいは段階的発生） 76 ドメインモデルドメイン記述実装発見された「ドメイン」知識一連の活動を通じて、ユーザー/開発者共に「ドメイン」に対する知識・理解を深め「ドメイン」を再定義する

Slide 77

Slide 77 text

77 一流シェフはお客の要望を完全に満足させる料理が作れる（中略）しかし超一流は違う客が予想もできない新しい皿を作り上げる ”あなた方が本当に食べたかったものはこれなのだ”……とそして人々は”まさにこれが求めていたものだ！今までどうして気づかなかったんだ！！”と神業に驚嘆するのよ将太の寿司2 4巻 28話「一流と超一流」より

Slide 78

Slide 78 text

「ドメイン」を深く知る見えている個別具体の知識に固執せず「私達は本当は何をしたいのか」「私達は本当はどうありたいのか」「私達はなぜここにいるのか」を繰り返し問い続け、更新し続ける 78

Slide 79

Slide 79 text

ユーザーと開発者の全体で「超一流」になる 79

Slide 80

Slide 80 text

「ドメイン駆動設計」is... 80

Slide 81

Slide 81 text

人と「ドメイン」の関係 81 ● 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、主観的であり非自律的である。

Slide 82

Slide 82 text

人と「ドメイン」の関係 82 ● 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、主観的であり非自律的である。 ● 私達は「ドメイン」の知識を予め記述しきることはできない。

Slide 83

Slide 83 text

人と「ドメイン」の関係 83 ● 「ドメイン」は、そこに関わるユーザーの関心・活動に基づくという点で、主観的であり非自律的である。 ● 私達は「ドメイン」の知識を予め記述しきることはできない。 ● 「ドメイン」を現実に動くソフトウェアにするために、私達は不断に「ドメイン」の記述を試み、暗黙だった知識を発見し、発見に基づいて「ドメイン」を再定義していく必要がある。

Slide 84

Slide 84 text

「ドメイン駆動設計」とは 84 ● 「人はドメインとどう関わるか、関わることができるか」の一般的な形式を言語化したもの

Slide 85

Slide 85 text

「ドメイン駆動設計」とは 85 ● 「人はドメインとどう関わるか、関わることができるか」の一般的な形式を言語化したもの ● そうして記述された「人」-「ドメイン」の関係性を前提に、「ドメイン」をソフトウェアという形で実現するための方法論

Slide 86

Slide 86 text

86 この方法なるものを料理の「作り方」とか自動車の操縦の「仕方」のような一定の結果を保証してくれる一連の「手続き」と考えるとすれば、それは論外である。方法とは本来、デカルトの解析の方法やヘーゲルの弁証法がそうであったように、思考のスタイル、研究対象に立ち向かう態度のことなのである。木田元「現象学」序章現象学とは何かより

Slide 87

Slide 87 text

「ドメイン駆動設計」とは 87 ● 「人はドメインとどう関わるか、関わることができるか」の一般的な形式を言語化したもの ● そうして記述された「人」-「ドメイン」の関係性を前提に、「ドメイン」をソフトウェアという形で実現するための方法論 ● ソフトウェアという形で「ドメイン」を実現するため、さしあたって有力と思われる道具を書き添えたもの

Slide 88

Slide 88 text

Evansが書き添えた道具 88 ● ドメインモデル ○ ユーザー/開発者/ソフトウェアを検証可能な形で結合させる ● ユビキタス言語 ○ 厳密なモデルの記述を支える ● 戦術的設計パターン ○ ソフトウェアという形へ落とし込む方法を提供する ○ 暗黙知の形式化を助ける ● 戦略的設計パターン ○ 大規模な構造を定義する方法を提供する ○ 暗黙知の形式化を助ける

Slide 89

Slide 89 text

「ドメイン駆動設計」を始めるために 89 ● 何はなくとも、まずは自分（達）が実現するべき「ドメイン」が何かを知ること。 ● 「ドメイン」を知るためには、単にユーザーの言葉を書き留めるのではなく、形式化されていない暗黙知を発見するよう務めることになる。 ● 蓄えた「ドメイン」の知識をどうやって記述するかという段階で、初めて様々な「道具」が関わってくる。

Slide 90

Slide 90 text

補足）Eric Evansによる「ドメイン駆動設計」の原則 90

Slide 91

Slide 91 text

ドメイン駆動のポイント・原理 Eric Evans — Tackling Complexity in the Heart of Software(01:30~) ● ドメインの中核となる複雑さと契機に注目せよ ● ソフトウェアエキスパートとドメインエキスパートのコラボレーションの中で、モデルを探索せよ ● モデルを明示的に表現するソフトウェアを記述せよ ● 限られた文脈で、特定のユビキタス言語を使って発話せよ（Youtube自動翻訳からの意訳） 91

Slide 92

Slide 92 text

コラボレーション 92 Eric Evans — Tackling Complexity in the Heart of Software(2:48~) 私達はその（business people, domain expert と呼ばれる）人に対して「そのビジネスを知っているのはあなたなのだから、（あなたが）モデルを提供してください」と言っているわけではありません。「私達はソフトウェアの責任者だからモデルを開発する」とも言いません。「うまくやっていくためには、（domain expertとsoftware expertが）一緒にやっていく必要がある」と言っているのです。（Youtube自動翻訳からの意訳、（）内は発表者による）

Slide 93

Slide 93 text

ユビキタス言語 93 Eric Evans — Tackling Complexity in the Heart of Software(3:52~) ソフトウェアはそのモデルを明示的に反映していなければならず、それがユビキタス言語に繋がります。（中略）最終的に、コラボレーション・探索 [exploration] ・プログラミングに至るまで全ての一連の筋道は、ドメインの課題をより正確かつ表現力豊かに語るための言語（＝ユビキタス言語）の進化を意味します。（中略）「ユビキタス」とは、（会話やドキュメンテーションも含めた）”どこでも” [everywhere] という意味です。ただし、”システム全体のどこでも” という意味ではありません。ユビキタス言語は限定された文脈の内部にあると言わなくてはなりません。（Youtube自動翻訳からの意訳、[]内は自動翻訳の字幕、（）内は発表者による）

Slide 94

Slide 94 text

参考資料(敬称略) 94 ● エリック・エヴァンスのドメイン駆動設計 ○ Eric Evans（著）今関剛（監訳）和智右桂、牧野祐子（訳） ● 暗黙知の次元 ○ Michael Polanyi（著）高橋勇夫（訳） ● 境界の現象学 ○ 河野哲也 ● 現象学 ○ 木田元 ● 新装版フッサールの現象学 ○ Dan Zahavi（著）工藤和男、中村拓也 (訳) ● Eric Evans — Tackling Complexity in the Heart of Software ○ https://www.youtube.com/watch?v=dnUFEg68ESM

Slide 95

Slide 95 text

参考資料(敬称略) 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（著）西村直人、角谷信太郎（訳）

Slide 96

Slide 96 text

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