Tweet
Tweet

Slide 1

Slide 1 text

「モデル」の二面性と設計を考える 1 @Philomagi 2020/06/02@吉祥寺.pm22 #kichijojipm

Slide 2

Slide 2 text

発表者 @Philomagi ● WEB系プログラマ ● 自称フロントエンド寄り ○ 最近のマイブームは SelfとSmalltalk ○ vanila jsも久しぶりにちょっと触りたい ● 設計の話とかが好きです ○ DDDとかクリーンアーキテクチャとか 2

Slide 3

Slide 3 text

切っ掛け ● 最近、設計をする時の「モデル」の組み立て方が変わってきた ● ユースケースから設計をスタートするのだけど、出来上がった「モデル」 には、ユースケース記述時点では存在しなかった用語が出てくるように なってきた ● 結果、設計や実装がいびつになるよりもむしろ、当初全く想定していな かったユースケースも吸収できそう or できた ● 何が変わってきたかと言ったら、「モデル」毎の性質を考えるようになっ たところかも？ 3

Slide 4

Slide 4 text

● 「モデル」には、「何が必要であるか(what is)」を記述するとい う側面と、「どのようにするか(how do)」を記述するという側 面、2つの側面が存在しているのではないか ● あるモデルの「what is」「how do」が何に根ざしているのか、 何に対する「what is」「how do」であるのかを明確にすること は、よりよい設計の実現を助けてくれるのではないか 今回のテーマ 4

Slide 5

Slide 5 text

「モデル」 5

Slide 6

Slide 6 text

6 ベースとする議論 https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm

Slide 7

Slide 7 text

7 ベースとする議論 https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm

Slide 8

Slide 8 text

ここでの「モデル」 8 解決したい問題領域について、 それを解決するために必要だと思われる情報 （名前、関連、etc...）を抽出して、 記号化・可視化したもの

Slide 9

Slide 9 text

「モデル」の二面性 9

Slide 10

Slide 10 text

「モデル」の二面性 10 「what is」の記述として 「how do」の記述として

Slide 11

Slide 11 text

「what is」の記述としての「モデル」 11 ● 問題領域の解決に必要な情報が「何であるか」を 記述したものとしての側面 ● 個々の記号や線で表現される ● いわゆる「モデル」について語られる時、（多分）専 ら注目される側面

Slide 12

Slide 12 text

「how do」の記述としての「モデル」 12 ● 問題領域を「どのように」解決するかを記述したも のとしての側面 ● 図全体によって表現される ● 「必要だと思われる情報を」抽出する＝問題を「ど のように」解決するかを定義する

Slide 13

Slide 13 text

「what is」と「how do」 13

Slide 14

Slide 14 text

「what is」と「how do」 14 この図が表現しているのは what is か？ how do か？

Slide 15

Slide 15 text

「what is」と「how do」 15 この図が表現しているのは what is か？ how do か？

Slide 16

Slide 16 text

「what is」と「how do」 16

Slide 17

Slide 17 text

「what is」と「how do」 17

Slide 18

Slide 18 text

「what is」と「how do」 18

Slide 19

Slide 19 text

「what is」と「how do」 19 問題領域の解決に必要な情報が「何 であるか = what is」は、個々の記号 ・線で記述される

Slide 20

Slide 20 text

「what is」と「how do」 20 問題領域を「どのように = how do」 解決するかは、図全体で表現される

Slide 21

Slide 21 text

「what is」と「how do」 21 ● 「Cを使ってA・Bを生成する」 ● 「Bのバリエーションとして E’ E’’ を 用いる」 ● 「Bの一覧をAという単位で管理す る」 ● etc...

Slide 22

Slide 22 text

「what is」と「how do」 22 このモデルに含まれる各要素（記号・ 図・線・名前 etc...）全体によって、対 象とする問題を「どのように」解決され るかが表現される

Slide 23

Slide 23 text

「what is」と「how do」の不可分性 23 ● 「what is」を変える = 記号や線が変わる ○ 図全体が変わるので、「how do」も変わる ● 「how do」を変える = 図全体の構造が変わる ○ 記号や線が変わる（名前、記号・線の種類、線の向き、 線の位置、etc...）ので、「what is」も変わる

Slide 24

Slide 24 text

「what is」と「how do」の不可分性 24

Slide 25

Slide 25 text

「what is」と「how do」の不可分性 25 仮に「A」という名前（＝what is）が「F」と いう名前に変わるということは、前提知 識が変わったということ。 前提が変わったなら、「問題をどのよう に解決するか」（＝how do）も変わって くる

Slide 26

Slide 26 text

「what is」と「how do」の不可分性 26

Slide 27

Slide 27 text

「what is」と「how do」の不可分性 27 そもそもの「どのように問題を解決 するか」（＝how do）が変わるな ら、モデルに登場する個々の記号 ・線（＝what is）も変化する

Slide 28

Slide 28 text

（再掲）「モデル」の二面性 28 「what is」の記述として 「how do」の記述として

Slide 29

Slide 29 text

（再掲）「what is」と「how do」の不可分性 29 ● 「what is」を変える = 記号や線が変わる ○ 図全体が変わるので、「how do」も変わる ● 「how do」を変える = 図全体の構造が変わる ○ 記号や線が変わる（名前、記号・線の種類、線の向き、 線の位置、etc...）ので、「what is」も変わる

Slide 30

Slide 30 text

「what is」と「how do」の不可分性 30 ● 「どのように解決するか（how do）」によって、必要 な知識が「何であるか（what is）」は変わる ● 必要な知識が「何であるか（what is）」が変わるな ら、「どのように解決するか（how do）」も変わる

Slide 31

Slide 31 text

「モデル」間のwhat is/how do 31

Slide 32

Slide 32 text

「what is」・「how do」の意義 32 「モデル」における「what is」「how do」という観点がど のように役立つのか？

Slide 33

Slide 33 text

「what is」・「how do」の意義 33 「モデル」における「what is」「how do」という観点がど のように役立つのか？ ↓ より良い設計を助けてくれる（かもしれない）

Slide 34

Slide 34 text

ドメインモデル と アプリケーションモデル で考えてみる 34

Slide 35

Slide 35 text

● ドメインモデル ○ 「ソフトウェアプログラムを使用するユーザの何らかの活 動や関心」をモデル化したもの ● アプリケーションモデル ○ アプリケーションが外部（ユーザー、他システム）に提供 する機能をモデル化したもの ここでの定義 35

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

アプリケーションモデルとドメインモデル間のwhat is / how do 37 ドメインモデル

Slide 38

Slide 38 text

アプリケーションモデルとドメインモデル間のwhat is / how do 38 ドメインモデル ● how do ○ ビジネスをどのように実現するか ● what is ○ ビジネス知識 ■ 用語 ■ ルール ■ 制約 etc...

Slide 39

Slide 39 text

アプリケーションモデルとドメインモデル間のwhat is / how do 39 ドメインモデル アプリケーションモデル ● how do ○ ビジネスをどのように実現するか ● what is ○ ビジネス知識 ■ 用語 ■ ルール ■ 制約 etc...

Slide 40

Slide 40 text

アプリケーションモデルとドメインモデル間のwhat is / how do 40 ドメインモデル ● how do ○ ビジネスをどのように実現するか ● what is ○ ビジネス知識 ■ 用語 ■ ルール ■ 制約 etc... アプリケーションモデル ● how do ○ 機能（ユースケース）をどのように実現 するか ● what is ○ 機能としての入力/出力 ○ ドメイン知識

Slide 41

Slide 41 text

アプリケーションモデルとドメインモデル間のwhat is / how do 41 ドメインモデル アプリケーションモデル ● how do ○ ビジネスをどのように実現するか ● what is ○ ビジネス知識 ■ 用語 ■ ルール ■ 制約 etc... ● how do ○ 機能（ユースケース）をどのように実現 するか ● what is ○ 機能としての入力/出力 ○ ドメイン知識

Slide 42

Slide 42 text

アプリケーションモデルとドメインモデル間のwhat is / how do 42 ドメインモデル アプリケーションモデル ● アプリケーションモデルにとって、 ドメインモデ ルは what is の一つ ● ドメインモデルは、アプリケーションそのものは 実現しない ● ドメインモデルは、アプリケーションを実現する ための語彙を提供する ● how do ○ ビジネスをどのように実現するか ● what is ○ ビジネス知識 ■ 用語 ■ ルール ■ 制約 etc... ● how do ○ 機能（ユースケース）をどのように実現 するか ● what is ○ 機能としての入力/出力 ○ ドメイン知識

Slide 43

Slide 43 text

ドメインモデルとアプリケーションモデル 43 ● アプリケーションモデルにとって、ドメインモデルは what is の一つ ● ドメインモデルは、アプリケーションそのものは実現しない ● ドメインモデルは、アプリケーションを実現するための語彙を提供する

Slide 44

Slide 44 text

ドメインモデルとアプリケーションモデル 44 ● アプリケーションモデルにとって、ドメインモデルは what is の一つ ● ドメインモデルは、アプリケーションそのものは実現しない ● ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？

Slide 45

Slide 45 text

ドメインモデルとアプリケーションモデル 45 ● アプリケーションモデルにとって、ドメインモデルは what is の一つ ● ドメインモデルは、アプリケーションそのものは実現しない ● ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？

Slide 46

Slide 46 text

ドメインモデルとアプリケーションモデル 46 ● アプリケーションモデルにとって、ドメインモデルは what is の一つ ● ドメインモデルは、アプリケーションそのものは実現しない ● ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？

Slide 47

Slide 47 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do 47

Slide 48

Slide 48 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do ● そのXはドメインか？＝ドメインモデルの what is か？ ○ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ○ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ 48

Slide 49

Slide 49 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do ● そのXはドメインか？＝ドメインモデルの what is か？ ○ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ○ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ ● そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ○ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ○ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 49

Slide 50

Slide 50 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do ● そのXはドメインか？＝ドメインモデルの what is か？ ○ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ○ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ ● そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ○ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ○ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 50

Slide 51

Slide 51 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do ● そのXはドメインか？＝ドメインモデルの what is か？ ○ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ○ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか ？ ● そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ○ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ○ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか ？ 51

Slide 52

Slide 52 text

「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do ● そのXはドメインか？＝ドメインモデルの what is か？ ○ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ○ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ ● そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ○ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ○ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 52

Slide 53

Slide 53 text

変わったこと・変わらなかったこと ● 変わったこと ○ ユースケースを元に、それが実現するために必要な知識・ルール・ 制約（＝ドメインモデルのwhat is）を探し、定義するようになった ○ 個別の知識（what is）だけでなく、全体の形（how do）と照らして判 断することが多くなった ● 変わらなかったこと ○ 整理・分割の基本的な方法 ○ SOLID、抽象度の統一、DRY、etc… と、昔から知られている原則が やはり活躍する 53

Slide 54

Slide 54 text

今回のテーマ ● 対象となるドメインの知識を表現しつつ、複数のユースケースを横断するような モデルに対する考察 ● このようなモデルが実現する時、そのモデルは誰にどのような恩恵を与えるの か ● このようなモデルが実現する時、そのモデルにはどのような性質が備わっている のか ● このようなモデルを実現するために、私達が取れるアプローチとして何が考えら れるか 54

Slide 55

Slide 55 text

● 「どのように」の記述としての側面 ○ そのモデルが表現する知識を「どのように」捉えたか ○ 言葉、関連、構造、etc... ● 「何を」の記述としての側面 ○ そのモデルによって、「何を」解決するのか 55

Slide 56

Slide 56 text

メモ 意味、無意味、非意味 静的な定義、動的な利用 知識・ルール・制約に対して意味的なモデル 利益・価値・活用に対して非意味的なモデル 両者を分かつための古典的アプローチ = 「抽象度を揃える」 56

Slide 57

Slide 57 text

メモ 「抽象度を揃える」＝パッケージ内部を全て、同じ観点で意味的であり、同じ観点で非 意味的にする ● ex. ドメイン層内部は、全てドメイン知識の表現という点で意味的であり、ユース ケースの実現という観点で非意味的 ● ex. ユースケース層内部は、全てユースケースの実現という観点で意味的であ り、実現結果の表現という観点で非意味的 ● ex. プレゼンテーション層は、全て実現結果の表現という観点で意味的であり、 実現結果を具体的に形にする（ブラウザ、APIクライアント）方法という点で非意 味的 57

Slide 58

Slide 58 text

メモ あるパッケージは、特定の一つの観点においてのみ意味的であるべき（SRP） 有るパッケージは、複数の観点において非意味的で良い（特定の一つの意味でのみ 意味的であるなら、それ以外については非意味的か無意味にならざるを得ない （？）） あるパッケージの非意味的側面は、別のパッケージによって形にされる。 パッケージAがXにおいて非意味的であり、パッケージBがXにおいて意味的である 時、パッケージBはパッケージAを用いてXを実現することができる 58

Slide 59

Slide 59 text

メモ パッケージAがXにおいて非意味的であり、パッケージBがXにおいて意味的である 時、パッケージBはパッケージAを用いてXを実現することができる。この時、Bからは AがXのために有るかのように見えるし、実際そう解釈しても良い。 一方、パッケージAがYにおいて非意味的であり、パッケージCがYにおいて意味的で ある時、パッケージCもAを用いてYを実現することができる。この時、BからはAがXの ために有るかのように見えるし、実際そう解釈しても良い。 AはXにもYにも非意味的であるが故に、 59

Slide 60

Slide 60 text

メモ AはXにもYにも非意味的であるが故に（XやYと固定的に結合していないが故に）、X にもYにも活用できる。AがXやYの一方と結合していた場合、XとYが排他である場合 にはAをYの実現に利用することはできない。 抽象度が揃っていない（あるパッケージの意味的性質が、複数の観点によって定め られている）状態では、そのパッケージ内部のモジュールは複数の（観点から定めら れた）意味と結合していることになる。 60

Slide 61

Slide 61 text

メモ ここまでを具体化して、モデルとユースケースの関係に戻ると、モデルの抽象度が 揃っていない（＝複数の観点による「意味」を持つ）場合、あるモデルは特定のユース ケースと強く結びついた状態ということになる。 この時、そのモデルは結合したユースケースには十分に力を発揮するが、他のユー スケースでの活用は難しいあるいは不可能である。 ユースケースを横断可能なモデルを定義するためには、モデルは特定のユースケー スとは結合してはならない。ユースケースから導かれたものであったとしても、最終的 にはユースケースそれ自体とは分断されなくてはならない。 61

Slide 62

Slide 62 text

メモ では「ユースケースから分断されたモデル」「ユースケースと結合しないモデル」とは 何か、どのようにしてそのようなモデルを発見するのか。 モデルは、ドメイン（＝人々の活動・関心の内、ソフトウェアを通じて実現しようとして いる領域）の知識（ルール・制約・関連・語彙）を表現するものでなくてはならず、ま た、ただそれだけのものでなくてはならない（UNIX・一つのことを上手くやる）。それ以 外の関心事・観点を含んではならない（SRP）。 アプリケーション上の特定の機能・ユースケース・処理手続きの知識を持ってはなら ない。 62

Slide 63

Slide 63 text

メモ 還元すれば、ユースケースを横断するようなモデルを定義するためには、そこにHow を含んではならない。ただWhatを記述する。 また、モデルに含まれるものはあくまで関心事・活動の表現であり、ソフトウェアその ものであってはならない。そこにあるのはソフトウェアを形にするための道具でしかな い。 その道具を用いてソフトウェアを実現するのがユースケースの責務・関心事である。 どの道具をどのように用いるかはユースケースに委ねられる。ただし、ドメインにおい て存在する制約を満たす範囲内において。 63

Slide 64

Slide 64 text

切っ掛け（あるいは元ネタ） 64

Slide 65

Slide 65 text

65 https://twitter.com/manabuueno/status/1198255449188888576

Slide 66

Slide 66 text

「縦に貫く」に対する感想 66 最初に読んだ時の感想 ● 部分的には、「なるほど」と納得できた ○ 「個別のユースケース毎に作ってたら、ちょっと変わるだけでまた作 り直しになりがち」 ● 一方、部分的には違和感を覚え、上手く消化できなかった ○ 「個別の”コンテクスト”毎に分離しないと、ぐちゃぐちゃになって終わ りそうな気がする」

Slide 67

Slide 67 text

「縦に貫く」に対する感想 今、改めて読んでの感想 ● 「あ、こういうことだった？」という感覚 ● 最近のプロダクト開発でも、ユースケースを「縦に貫く」ような設計をして いた気がする ● 「コンテクストを分け、それぞれで最適な実装を作る」という方針とも矛盾 しないのでは？という感覚 67

Slide 68

Slide 68 text

参考資料 68 ● モデルとは何であって、何でないのか ○ https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm ● 「ユースケースにただ対処するだけだと、全体の情報量はデザインの分だけむしろ増えてしまう」 ○ https://twitter.com/manabuueno/status/1198255449188888576 ● design ○ https://www.oxfordlearnersdictionaries.com/definition/english/design_1?q=design

Slide 69

Slide 69 text

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