「モデル」の二面性と設計を考える / dual nature of "model"

https://kichijojipm.connpass.com/event/177459/ での発表内容です

Transcript

1. 「モデル」の二面性と設計を考える 1 @Philomagi 2020/06/02@吉祥寺.pm22 #kichijojipm
2. 発表者 @Philomagi • WEB系プログラマ • 自称フロントエンド寄り ◦ 最近のマイブームは SelfとSmalltalk ◦ vanila jsも久しぶりにちょっと触りたい • 設計の話とかが好きです ◦ DDDとかクリーンアーキテクチャとか 2
3. 切っ掛け • 最近、設計をする時の「モデル」の組み立て方が変わってきた • ユースケースから設計をスタートするのだけど、出来上がった「モデル」 には、ユースケース記述時点では存在しなかった用語が出てくるように なってきた • 結果、設計や実装がいびつになるよりもむしろ、当初全く想定していな かったユースケースも吸収できそう or できた • 何が変わってきたかと言ったら、「モデル」毎の性質を考えるようになっ たところかも？ 3
4. • 「モデル」には、「何が必要であるか(what is)」を記述するとい う側面と、「どのようにするか(how do)」を記述するという側 面、2つの側面が存在しているのではないか • あるモデルの「what is」「how do」が何に根ざしているのか、 何に対する「what is」「how do」であるのかを明確にすること は、よりよい設計の実現を助けてくれるのではないか 今回のテーマ 4
5. 「モデル」 5
6. 6 ベースとする議論 https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
7. 7 ベースとする議論 https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm
8. ここでの「モデル」 8 解決したい問題領域について、 それを解決するために必要だと思われる情報 （名前、関連、etc...）を抽出して、 記号化・可視化したもの
9. 「モデル」の二面性 9
10. 「モデル」の二面性 10 「what is」の記述として 「how do」の記述として
11. 「what is」の記述としての「モデル」 11 • 問題領域の解決に必要な情報が「何であるか」を 記述したものとしての側面 • 個々の記号や線で表現される • いわゆる「モデル」について語られる時、（多分）専 ら注目される側面
12. 「how do」の記述としての「モデル」 12 • 問題領域を「どのように」解決するかを記述したも のとしての側面 • 図全体によって表現される • 「必要だと思われる情報を」抽出する＝問題を「ど のように」解決するかを定義する
13. 「what is」と「how do」 13
14. 「what is」と「how do」 14 この図が表現しているのは what is か？ how do か？
15. 「what is」と「how do」 15 この図が表現しているのは what is か？ how do か？
16. 「what is」と「how do」 16
17. 「what is」と「how do」 17
18. 「what is」と「how do」 18
19. 「what is」と「how do」 19 問題領域の解決に必要な情報が「何 であるか = what is」は、個々の記号 ・線で記述される
20. 「what is」と「how do」 20 問題領域を「どのように = how do」 解決するかは、図全体で表現される
21. 「what is」と「how do」 21 • 「Cを使ってA・Bを生成する」 • 「Bのバリエーションとして E’ E’’ を 用いる」 • 「Bの一覧をAという単位で管理す る」 • etc...
22. 「what is」と「how do」 22 このモデルに含まれる各要素（記号・ 図・線・名前 etc...）全体によって、対 象とする問題を「どのように」解決され るかが表現される
23. 「what is」と「how do」の不可分性 23 • 「what is」を変える = 記号や線が変わる ◦ 図全体が変わるので、「how do」も変わる • 「how do」を変える = 図全体の構造が変わる ◦ 記号や線が変わる（名前、記号・線の種類、線の向き、 線の位置、etc...）ので、「what is」も変わる
24. 「what is」と「how do」の不可分性 24
25. 「what is」と「how do」の不可分性 25 仮に「A」という名前（＝what is）が「F」と いう名前に変わるということは、前提知 識が変わったということ。 前提が変わったなら、「問題をどのよう に解決するか」（＝how do）も変わって くる
26. 「what is」と「how do」の不可分性 26
27. 「what is」と「how do」の不可分性 27 そもそもの「どのように問題を解決 するか」（＝how do）が変わるな ら、モデルに登場する個々の記号 ・線（＝what is）も変化する
28. （再掲）「モデル」の二面性 28 「what is」の記述として 「how do」の記述として
29. （再掲）「what is」と「how do」の不可分性 29 • 「what is」を変える = 記号や線が変わる ◦ 図全体が変わるので、「how do」も変わる • 「how do」を変える = 図全体の構造が変わる ◦ 記号や線が変わる（名前、記号・線の種類、線の向き、 線の位置、etc...）ので、「what is」も変わる
30. 「what is」と「how do」の不可分性 30 • 「どのように解決するか（how do）」によって、必要 な知識が「何であるか（what is）」は変わる • 必要な知識が「何であるか（what is）」が変わるな ら、「どのように解決するか（how do）」も変わる
31. 「モデル」間のwhat is/how do 31
32. 「what is」・「how do」の意義 32 「モデル」における「what is」「how do」という観点がど のように役立つのか？
33. 「what is」・「how do」の意義 33 「モデル」における「what is」「how do」という観点がど のように役立つのか？ ↓ より良い設計を助けてくれる（かもしれない）
34. ドメインモデル と アプリケーションモデル で考えてみる 34
35. • ドメインモデル ◦ 「ソフトウェアプログラムを使用するユーザの何らかの活 動や関心」をモデル化したもの • アプリケーションモデル ◦ アプリケーションが外部（ユーザー、他システム）に提供 する機能をモデル化したもの ここでの定義 35
36. 「ドメイン」とは何か 36 すべてのソフトウェアプログラムは、それを使用する ユーザの何らかの活動や関心と関係がある。ユーザ がプログラムを適用するこの対象領域が、ソフトウェア のドメインである。 -「エリック・エヴァンスのドメイン駆動設計」p.2
37. アプリケーションモデルとドメインモデル間のwhat is / how do 37 ドメインモデル
38. アプリケーションモデルとドメインモデル間のwhat is / how do 38 ドメインモデル • how do ◦ ビジネスをどのように実現するか • what is ◦ ビジネス知識 ▪ 用語 ▪ ルール ▪ 制約 etc...
39. アプリケーションモデルとドメインモデル間のwhat is / how do 39 ドメインモデル アプリケーションモデル • how do ◦ ビジネスをどのように実現するか • what is ◦ ビジネス知識 ▪ 用語 ▪ ルール ▪ 制約 etc...
40. アプリケーションモデルとドメインモデル間のwhat is / how do 40 ドメインモデル • how do ◦ ビジネスをどのように実現するか • what is ◦ ビジネス知識 ▪ 用語 ▪ ルール ▪ 制約 etc... アプリケーションモデル • how do ◦ 機能（ユースケース）をどのように実現 するか • what is ◦ 機能としての入力/出力 ◦ ドメイン知識
41. アプリケーションモデルとドメインモデル間のwhat is / how do 41 ドメインモデル アプリケーションモデル • how do ◦ ビジネスをどのように実現するか • what is ◦ ビジネス知識 ▪ 用語 ▪ ルール ▪ 制約 etc... • how do ◦ 機能（ユースケース）をどのように実現 するか • what is ◦ 機能としての入力/出力 ◦ ドメイン知識
42. アプリケーションモデルとドメインモデル間のwhat is / how do 42 ドメインモデル アプリケーションモデル • アプリケーションモデルにとって、 ドメインモデ ルは what is の一つ • ドメインモデルは、アプリケーションそのものは 実現しない • ドメインモデルは、アプリケーションを実現する ための語彙を提供する • how do ◦ ビジネスをどのように実現するか • what is ◦ ビジネス知識 ▪ 用語 ▪ ルール ▪ 制約 etc... • how do ◦ 機能（ユースケース）をどのように実現 するか • what is ◦ 機能としての入力/出力 ◦ ドメイン知識
43. ドメインモデルとアプリケーションモデル 43 • アプリケーションモデルにとって、ドメインモデルは what is の一つ • ドメインモデルは、アプリケーションそのものは実現しない • ドメインモデルは、アプリケーションを実現するための語彙を提供する
44. ドメインモデルとアプリケーションモデル 44 • アプリケーションモデルにとって、ドメインモデルは what is の一つ • ドメインモデルは、アプリケーションそのものは実現しない • ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？
45. ドメインモデルとアプリケーションモデル 45 • アプリケーションモデルにとって、ドメインモデルは what is の一つ • ドメインモデルは、アプリケーションそのものは実現しない • ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？
46. ドメインモデルとアプリケーションモデル 46 • アプリケーションモデルにとって、ドメインモデルは what is の一つ • ドメインモデルは、アプリケーションそのものは実現しない • ドメインモデルは、アプリケーションを実現するための語彙を提供する ↓ 「ドメインモデルからの知識の流出（＝貧血症）」のみならず、「ドメインモデルの過剰 な肥大化（＝高血圧症？）」の「臭い」を感じるための指標にならないか？
47. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do 47
48. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do • そのXはドメインか？＝ドメインモデルの what is か？ ◦ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ◦ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ 48
49. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do • そのXはドメインか？＝ドメインモデルの what is か？ ◦ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ◦ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ • そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ◦ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ◦ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 49
50. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do • そのXはドメインか？＝ドメインモデルの what is か？ ◦ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ◦ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ • そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ◦ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ◦ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 50
51. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do • そのXはドメインか？＝ドメインモデルの what is か？ ◦ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ◦ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか ？ • そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ◦ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ◦ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか ？ 51
52. 「Xはドメインか、アプリケーションか？」 「Xはドメインか、アプリケーションか？」を 考える問い立ての道具としての what is/how do • そのXはドメインか？＝ドメインモデルの what is か？ ◦ Xは、ドメインの知識（用語・ルール・制約）を表現したものか？ ◦ それを組み込んだドメインモデル全体 = how do は、「どのようにビジネスを実現するか」の記述 として成立しているか？ • そのXはアプリケーションか？＝アプリケーションモデルの what is か？ ◦ Xは、アプリケーションの知識（ユースケース、入力 /出力）を表現したものか？ ◦ それを組み込んだアプリケーションモデル全体 = how doは、「どのように機能を実現するか」の 記述として成立しているか？ 52
53. 変わったこと・変わらなかったこと • 変わったこと ◦ ユースケースを元に、それが実現するために必要な知識・ルール・ 制約（＝ドメインモデルのwhat is）を探し、定義するようになった ◦ 個別の知識（what is）だけでなく、全体の形（how do）と照らして判 断することが多くなった • 変わらなかったこと ◦ 整理・分割の基本的な方法 ◦ SOLID、抽象度の統一、DRY、etc… と、昔から知られている原則が やはり活躍する 53
54. 今回のテーマ • 対象となるドメインの知識を表現しつつ、複数のユースケースを横断するような モデルに対する考察 • このようなモデルが実現する時、そのモデルは誰にどのような恩恵を与えるの か • このようなモデルが実現する時、そのモデルにはどのような性質が備わっている のか • このようなモデルを実現するために、私達が取れるアプローチとして何が考えら れるか 54
55. • 「どのように」の記述としての側面 ◦ そのモデルが表現する知識を「どのように」捉えたか ◦ 言葉、関連、構造、etc... • 「何を」の記述としての側面 ◦ そのモデルによって、「何を」解決するのか 55
56. メモ 意味、無意味、非意味 静的な定義、動的な利用 知識・ルール・制約に対して意味的なモデル 利益・価値・活用に対して非意味的なモデル 両者を分かつための古典的アプローチ = 「抽象度を揃える」 56
57. メモ 「抽象度を揃える」＝パッケージ内部を全て、同じ観点で意味的であり、同じ観点で非 意味的にする • ex. ドメイン層内部は、全てドメイン知識の表現という点で意味的であり、ユース ケースの実現という観点で非意味的 • ex. ユースケース層内部は、全てユースケースの実現という観点で意味的であ り、実現結果の表現という観点で非意味的 • ex. プレゼンテーション層は、全て実現結果の表現という観点で意味的であり、 実現結果を具体的に形にする（ブラウザ、APIクライアント）方法という点で非意 味的 57
58. メモ あるパッケージは、特定の一つの観点においてのみ意味的であるべき（SRP） 有るパッケージは、複数の観点において非意味的で良い（特定の一つの意味でのみ 意味的であるなら、それ以外については非意味的か無意味にならざるを得ない （？）） あるパッケージの非意味的側面は、別のパッケージによって形にされる。 パッケージAがXにおいて非意味的であり、パッケージBがXにおいて意味的である 時、パッケージBはパッケージAを用いてXを実現することができる 58
59. メモ パッケージAがXにおいて非意味的であり、パッケージBがXにおいて意味的である 時、パッケージBはパッケージAを用いてXを実現することができる。この時、Bからは AがXのために有るかのように見えるし、実際そう解釈しても良い。 一方、パッケージAがYにおいて非意味的であり、パッケージCがYにおいて意味的で ある時、パッケージCもAを用いてYを実現することができる。この時、BからはAがXの ために有るかのように見えるし、実際そう解釈しても良い。 AはXにもYにも非意味的であるが故に、 59
60. メモ AはXにもYにも非意味的であるが故に（XやYと固定的に結合していないが故に）、X にもYにも活用できる。AがXやYの一方と結合していた場合、XとYが排他である場合 にはAをYの実現に利用することはできない。 抽象度が揃っていない（あるパッケージの意味的性質が、複数の観点によって定め られている）状態では、そのパッケージ内部のモジュールは複数の（観点から定めら れた）意味と結合していることになる。 60
61. メモ ここまでを具体化して、モデルとユースケースの関係に戻ると、モデルの抽象度が 揃っていない（＝複数の観点による「意味」を持つ）場合、あるモデルは特定のユース ケースと強く結びついた状態ということになる。 この時、そのモデルは結合したユースケースには十分に力を発揮するが、他のユー スケースでの活用は難しいあるいは不可能である。 ユースケースを横断可能なモデルを定義するためには、モデルは特定のユースケー スとは結合してはならない。ユースケースから導かれたものであったとしても、最終的 にはユースケースそれ自体とは分断されなくてはならない。 61
62. メモ では「ユースケースから分断されたモデル」「ユースケースと結合しないモデル」とは 何か、どのようにしてそのようなモデルを発見するのか。 モデルは、ドメイン（＝人々の活動・関心の内、ソフトウェアを通じて実現しようとして いる領域）の知識（ルール・制約・関連・語彙）を表現するものでなくてはならず、ま た、ただそれだけのものでなくてはならない（UNIX・一つのことを上手くやる）。それ以 外の関心事・観点を含んではならない（SRP）。 アプリケーション上の特定の機能・ユースケース・処理手続きの知識を持ってはなら ない。 62
63. メモ 還元すれば、ユースケースを横断するようなモデルを定義するためには、そこにHow を含んではならない。ただWhatを記述する。 また、モデルに含まれるものはあくまで関心事・活動の表現であり、ソフトウェアその ものであってはならない。そこにあるのはソフトウェアを形にするための道具でしかな い。 その道具を用いてソフトウェアを実現するのがユースケースの責務・関心事である。 どの道具をどのように用いるかはユースケースに委ねられる。ただし、ドメインにおい て存在する制約を満たす範囲内において。 63
64. 切っ掛け（あるいは元ネタ） 64
65. 65 https://twitter.com/manabuueno/status/1198255449188888576
66. 「縦に貫く」に対する感想 66 最初に読んだ時の感想 • 部分的には、「なるほど」と納得できた ◦ 「個別のユースケース毎に作ってたら、ちょっと変わるだけでまた作 り直しになりがち」 • 一方、部分的には違和感を覚え、上手く消化できなかった ◦ 「個別の”コンテクスト”毎に分離しないと、ぐちゃぐちゃになって終わ りそうな気がする」
67. 「縦に貫く」に対する感想 今、改めて読んでの感想 • 「あ、こういうことだった？」という感覚 • 最近のプロダクト開発でも、ユースケースを「縦に貫く」ような設計をして いた気がする • 「コンテクストを分け、それぞれで最適な実装を作る」という方針とも矛盾 しないのでは？という感覚 67
68. 参考資料 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
69. ご清聴ありがとうございました 69