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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

5. 「モデル」
   5
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. 「モデル」の二面性
   9
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

13. 「what is」と「how do」
    13
    

    View Slide

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

    View Slide

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

    View Slide

16. 「what is」と「how do」
    16
    

    View Slide

17. 「what is」と「how do」
    17
    

    View Slide

18. 「what is」と「how do」
    18
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide