Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

philomagi
April 20, 2020

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

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

philomagi

April 20, 2020
Tweet

More Decks by philomagi

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  10. 「人」と「ドメイン」
    10

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. 「ドメイン」を知る
    33

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    ! or ?
    ドメイン

    View Slide

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

    ! or ?
    ドメイン
    ソフトウェアがどの程度「ドメイン」を
    正確に表現しているか、理解が難しい

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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(著)西村 直人、角谷 信太郎(訳)

    View Slide

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

    View Slide