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