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

WEBフロントエンドにおけるソフトウェア設計の考察

philomagi
February 09, 2020

 WEBフロントエンドにおけるソフトウェア設計の考察

philomagi

February 09, 2020
Tweet

More Decks by philomagi

Other Decks in Technology

Transcript

  1. WEBフロントエンドにおける
    ソフトウェア設計の考察
    1
    @Philomagi
    2020/02/[email protected] Doでしょう #17
    #javado

    View Slide

  2. 発表者
    @Philomagi
    ● 主にフロントエンド主体のWEB系エンジニア
    ● ScalaとTypescriptとRubyが好き
    ○ Rubyは最近、公私共に若干疎遠
    ● PHPは中々縁が切れない悪友
    ○ 最近は、「然程悪いやつでもないな」と思い始めてる
    2

    View Slide


  3. 以降、特に断りが無い場合は
    「フロントエンド = Webフロントエンド」
    の意味で使います
    3

    View Slide


  4. ● 今の主な関心事がWebフロントエンド
    ● 他のフロントアプリ事情に詳しくない
    ○ iOS/Android/デスクトップとか
    という理由です
    4

    View Slide

  5. 目次
    1. 現代フロントエンドの難しさ
    2. フロントエンドの「ドメイン」
    3. フロントエンドを「設計」する
    4. フロントエンドアーキテクチャ考察
    5

    View Slide

  6. 主張したいこと
    ● 現代のフロントエンドは単に「画面表示」と言えるほ
    ど単純ではない
    ● 「ロジック」も「ドメイン」も、フロントエンドには存在す

    ● 「画面設計」だけでなく「ソフトウェア設計」も、フロン
    トエンドには必要
    6

    View Slide

  7. 反論したいこと
    ❌ フロントエンドは表示して終わり
    ❌ 表示だけなので、「ドメイン」も「ロジック」も存在しな

    ❌ フロントエンドの「設計」と言えば「画面設計」(で終
    わる議論)
    7

    View Slide

  8. 1. 現代フロントエンドの難しさ
    8

    View Slide

  9. フロントエンドといえば
    9

    View Slide

  10. 開発環境の多様化・複雑化
    10

    View Slide

  11. 開発環境の多様化・複雑化
    11
    本質的な問題ではない

    View Slide

  12. 開発環境の多様化・複雑化
    12
    道具選びが大変なのは事実

    View Slide

  13. 開発環境の多様化・複雑化
    13
    しかし
    フロントエンドの難しさ = 道具選び
    ではない

    View Slide

  14. フロントエンドを
    複雑にするもの
    14

    View Slide

  15. ユーザー操作の複雑化
    ● よりリッチ/インタラクティブなUI
    ● 操作のバリエーション増加
    ● 入力バリデーションの組み合わせ
    画面に対する操作が複雑になっている
    15

    View Slide

  16. 画面状態の複雑化
    16
    ● 状態毎に複雑に切り替わる表示内容
    ● 複数状態の組み合わせによる表示変化
    ● 操作に応じて動的に切り替わる画面表示
    画面の表示状態が複雑になっている

    View Slide

  17. 現代フロントエンドの複雑さ
    17
    ● 複雑なユーザー操作
    ● 複雑な画面状態

    View Slide

  18. 現代フロントエンドの難しさ
    18
    ● 複雑なユーザー操作
    ● 複雑な画面状態
    この2点を如何に捉え管理するか

    View Slide

  19. 2. フロントエンドの「ドメイン」
    19

    View Slide

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

    View Slide

  21. フロントエンドの「ドメイン」を探る
    21
    フロントエンドが対象とする
    「ユーザの何らかの活動や関心」は何か?

    View Slide

  22. 再掲)現代フロントエンドの複雑さ
    22
    ● 複雑なユーザー操作
    ● 複雑な画面状態
    この2点を如何に捉え管理するか

    View Slide

  23. 再掲)現代フロントエンドの複雑さ
    23
    ● 複雑なユーザー操作
    ● 複雑な画面状態
    この2点を如何に捉え管理するか
    なぜこの2点が複雑化するのか?

    View Slide

  24. 操作と状態が複雑化する理由
    24
    それがフロントエンドのユーザの
    主たる「活動や関心」だから

    View Slide

  25. 「ポップアップメニュー」のエピソード
    25
    いつものカット・アンド・ペーストをやったとき、(中略)ピー
    ター・ドイッチュが立ち上がってスクリーンを指さしていた。
    「今やったのは、やったんじゃないかと俺が思ってること
    か?」
    「未来をつくった人々」 - Chapter15, p.323
    注:「ポップアップメニュー」の先駆けが初めてデモされた時のエピソード。 BitBltという技術の開発
    により、オーバーラッピングウィンドウが実用化されたことに依る。

    View Slide

  26. フロントエンドのドメイン
    26
    ユーザーが「した」と思ったことを
    画面に表すこと

    View Slide

  27. フロントエンドのドメイン
    27
    操作(「した」)

    表示(画面に表す)

    View Slide

  28. 3. フロントエンドを「設計」する
    28

    View Slide

  29. フロントエンドの何を「設計」するのか
    29
    2種類の「設計」対象が存在する
    ● 画面
    ○ ex. Atomic Design, UIデザイン
    ● ソフトウェア
    ○ ex. モジュール設計, 依存設計

    View Slide

  30. フロントエンド「設計」への問題提起
    30
    画面の「設計」ばかりが語られていないか?
    ● 画面の「設計」は重要だが、それだけで完結
    はしない(はず)
    ● 画面の奥にあるソフトウェアをいかに組み立
    てるかの議論が不足していないか?

    View Slide

  31. Atomic Designと「設計」
    31
    ● Atomic Design はUIパーツの設計方法論
    ○ ソフトウェアの設計までカバーするものでは
    ない
    ○ Atomic Design のスコープは「UIパーツをど
    う組み立てるか」まで
    ○ Atomic Design で「設計」は完結しない

    View Slide

  32. 今回の発表が扱う「設計」
    32
    「画面設計」ではなく、
    「ソフトウェア設計」に焦点をあてる

    View Slide

  33. どうやって設計するのか?
    33
    フロントエンドソフトウェアを、どうやって設計するか?

    View Slide

  34. どうやって設計するのか?
    34
    フロントエンドソフトウェアを、どうやって設計するか?
    Atomic Design のような、
    フロントエンドソフトウェア設計の
    新たな方法が必要だ!

    View Slide

  35. どうやって設計するのか?
    35
    フロントエンドソフトウェアを、どうやって設計するか?
    Atomic Design のような、
    フロントエンドソフトウェア設計の
    新たな方法が必要だ!

    View Slide

  36. どうやって設計するのか?
    36
    フロントエンドソフトウェアを、どうやって設計するか?
    Atomic Design のような、
    フロントエンドソフトウェア設計の
    新たな方法が必要だ!
    (そうした方法を考えても良いけれど)
    有力な方法論が
    既に存在している

    View Slide

  37. オブジェクト指向
    37

    View Slide

  38. 再掲)フロントエンドのドメイン
    38
    操作(「した」)

    表示(画面に表す)

    View Slide

  39. オブジェクト指向をどのように用いるか?
    フロントエンドのドメインである
    「操作」と「表示」に注目する
    39

    View Slide

  40. オブジェクト指向をどのように用いるか?
    フロントエンドのドメインである
    「操作」と「表示」に注目する
    40

    「操作」と「表示」に関わる要素を
    オブジェクトとして抽出する

    View Slide

  41. サンプル
    41

    View Slide

  42. 複雑な「操作ルール」を考える
    42

    View Slide

  43. 複雑な「操作ルール」を考える
    43
    Loading中は
    クリックしても反応しない

    View Slide

  44. 複雑な「操作ルール」を考える
    44

    View Slide

  45. 複雑な「操作ルール」を考える
    45
    Loading後は
    クリックするとポップアップ

    View Slide

  46. 複雑な「操作ルール」を考える
    46
    Loading後は
    クリックすると再読み込み

    View Slide

  47. 複雑な「操作ルール」を考える
    47

    View Slide

  48. 複雑な「操作ルール」を考える
    48

    View Slide

  49. 複雑な「操作ルール」を考える
    49

    View Slide

  50. 複雑な「操作ルール」を考える
    50

    View Slide

  51. 複雑な「操作ルール」を考える
    51
    Stateパターン

    View Slide

  52. 複雑な「操作ルール」を考える
    52
    Strategyパターン

    View Slide

  53. 複雑な「操作ルール」を考える
    53
    (有る種の)MVC

    View Slide

  54. オブジェクト指向をどのように用いるか?
    ● 基本は他のソフトウェアと変わらない
    ○ 必要なオブジェクトを分析し
    ○ オブジェクト間の関連を組み立てて
    ○ オブジェクトの振る舞いを実装する
    ● 一般に用いられる設計手法も活用する
    54

    View Slide

  55. 要するに
    「ちゃんと設計しよう」
    「ちゃんとオブジェクト考えよう」
    って言ってるだけじゃない?
    55

    View Slide

  56. YES
    56

    View Slide

  57. YES
    57
    その「ちゃんと」が大変で難しいけれど ……

    View Slide

  58. 再掲)フロントエンド「設計」への問題提起
    58
    画面の「設計」ばかりが語られていないか?
    ● 画面の「設計」は重要だが、それだけで完結
    はしない(はず)
    ● 画面の奥にあるソフトウェアをいかに組み立
    てるかの議論が不足していないか?

    View Slide

  59. 注意点
    ● 関心の中心が「表示」と「操作」であること
    ● サーバーサイドだと「UI層の話」として、あまり気に
    しない部分が中心
    ● サーバーサイドの感覚のままで考えると、オブジェ
    クトや関連を見落としやすいと思う
    59

    View Slide

  60. 60
    横道)フロントエンドと「ロジック」
    ● ここで言う「ロジック」とは何か?
    ● 「ロジック」=ビジネスルール・業務ルールとは限らない
    ○ 「ロジック」といえばビジネスルール・業務ルールというのは、主にバックエンドというコンテクスト
    における表現
    ○ この意味での「ロジック」ならば、フロントエンドには無い(むしろ、有ってはいけない)
    ● フロントエンドにおける「ロジック」は、表示と操作のルール
    ○ そもそもフロントエンドとバックエンドでコンテクストが異なるのだから、「ロジック」が同じ意味で
    あるという保証は無い
    ○ むしろ、それぞれ関心事が違うのだから、扱う「ロジック」は異なって当然

    View Slide

  61. 4. フロントエンドアーキテクチャ考察
    61

    View Slide

  62. フロントエンドアーキテクチャの候補
    62
    ● フロントエンドソフトウェアの設計
    ○ オブジェクト指向が有力そう
    ● フロントエンドソフトウェアのアーキテクチャ
    ○ ???

    View Slide

  63. Fluxアーキテクチャ
    63
    https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/

    View Slide

  64. Fluxアーキテクチャ
    64
    https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/

    View Slide

  65. Fluxアーキテクチャへの見解
    ● Fluxは強力だが、Fluxだけでアーキテクチャを完結させるのは厳しい
    ● 単方向データフローは有用だが、データフローを動作させるモジュールの
    構造については何も提供しない
    ○ 巨大な泥団子、単なる巨大グローバル変数になりがち
    ● 何か他のアーキテクチャ論と組み合わせて使うことになると思う
    ● フロントエンドにおけるCQRS(+ES)という見方は有力かも
    ○ cf. Almin.js | JavaScriptアーキテクチャ
    ○ CQRS(+ES)の知見が薄いので、今回は深堀りしない
    65

    View Slide

  66. Fluxアーキテクチャへの見解
    ● Fluxは強力だが、Fluxだけでアーキテクチャを完結させるのは厳しい
    ● 単方向データフローは有用だが、データフローを動作させるモジュールの
    構造については何も提供しない
    ○ 巨大な泥団子、単なる巨大グローバル変数になりがち
    ● 何か他のアーキテクチャ論と組み合わせて使うことになると思う
    ● フロントエンドにおけるCQRS(+ES)という見方は有力かも
    ○ cf. Almin.js | JavaScriptアーキテクチャ
    ○ CQRS(+ES)の知見が薄いので、今回は深堀りしない
    66

    View Slide

  67. 他のアーキテクチャ
    67

    View Slide

  68. 68
    Clean Architecture (Kindle位置No.3141)

    View Slide

  69. フロントエンドで
    クリーンアーキテクチャ(CA)?

    69

    View Slide

  70. 70
    Clean Architecture (Kindle位置No.3141)

    View Slide

  71. こんな薄い層できるの?
    外周でやって意味有るの?
    71

    View Slide

  72. 72
    フロントにおけるCAの意義
    クリーンアーキテクチャの四重円は単なる例。
    図22-1の円は、概要を示したものである。したがって、この4つ以外に
    も必要なものはあるだろう。この4つ以外は認めないというルールは
    ない。ただし、依存性のルールは常に適用される。ソースコードの依
    存性は常に内側に向けるべきだ。
    Clean Architecture (Kindle 位置No.3188)

    View Slide

  73. 73
    フロントにおけるCAの意義
    クリーンアーキテクチャの四重円は単なる例。
    図22-1の円は、概要を示したものである。したがって、この4つ以外に
    も必要なものはあるだろう。この4つ以外は認めないというルールは
    ない。ただし、依存性のルールは常に適用される。ソースコードの依
    存性は常に内側に向けるべきだ。
    Clean Architecture (Kindle 位置No.3188)

    View Slide

  74. 74
    フロントにおけるCAの意義
    重要なのは同心円ではなく
    依存性のルール

    View Slide

  75. 75
    フロントにおけるCAの意義
    重要なのは同心円ではなく
    依存性のルール

    この「4重の同心円」という
    形を守る必要は無い

    View Slide

  76. それならば
    76

    View Slide

  77. 77
    UI層
    View
    Controller
    Model
    State
    Action
    UI層の中で、さらに依存
    関係の階層を作る

    View Slide

  78. 78
    UI層
    View
    Controller
    Model
    State
    Action
    UI層の同心円内で依存
    性のルールを守り

    View Slide

  79. 79
    UI層
    View
    Controller
    Model
    State
    Action
    UI層とその内部の層で
    も依存性のルールを守

    View Slide

  80. 80
    Clean Architecture (Kindle位置No.3141)
    この同心円の図も、システムの
    ほんの一面的な表現でしかない

    View Slide

  81. Clean Architecture (Kindle位置No.3141) 81

    View Slide

  82. Clean Architecture (Kindle位置No.3141) 82
    デバイス・DB・ウェブ・UIが外周に在るのは、
    それらに積極的に関心を持たない立場から
    システムを見ているから

    「外周のものは重視せず、中央のものを重視する」とい
    う表明に過ぎない。
    内外の関係は、この一通りではない。

    View Slide

  83. Clean Architecture (Kindle位置No.3141) 83
    DBの内部にはDBから見た
    デバイスの内部にはデバイスから見た
    UIの内部にはUIから見た
    内側(コア)と外側(周辺)が
    それぞれ有ると考えたほうが自然

    View Slide

  84. 84

    View Slide

  85. 85
    同心円は入れ子状の構造になる

    View Slide

  86. 86

    View Slide

  87. 87

    View Slide

  88. 88
    参考)iOSアプリのクリーンアーキテクチャ
    @takasekさんによる発表資料
    ● クリーンアーキテクチャの同心円を、山に例
    えて説明。最終的に山は 連峰へ
    ● WebフロントエンドとiOSアプリの違いは有る
    が、主張の内容としては近い?
    ● 「単純化された創界山に引きずられず、思考
    停止せずに丁寧に設計していきましょう」 -
    p.41

    View Slide

  89. 89
    UI層
    View
    Controller
    Model
    State
    Action

    View Slide

  90. サンプルで考える
    90

    View Slide

  91. サンプルで考える
    91
    View

    View Slide

  92. サンプルで考える
    92
    View
    Controller/Applcaton

    View Slide

  93. サンプルで考える
    93
    View
    Controller/Applcaton
    Model

    View Slide

  94. 94
    サンプルで試した感触
    ● フロントエンドでも、クリーンアーキテクチャによる階層の整
    理は有用そうだった
    ○ 中心の関心事(状態・操作)と周辺の関心事(html/css、DIやバインディング)を分け
    て思考・実装できる
    ○ サンプルはVue.jsで実装したが、React、あるいはjQueryにも(バインディングを頑張っ
    て書けば)移植できそう!?→フレームワーク非依存
    ● 「中心の関心事と周辺の関心事を分けて思考・実装できる」
    ことが大きい

    View Slide

  95. まとめ
    95

    View Slide

  96. フロントエンドのドメイン
    96
    ● フロントエンドのドメインは「操作」と「状態」
    ● ユーザーが「した」と思ったことを現実にするた
    めに、この2つをいかに管理するか

    View Slide

  97. フロントエンドと「設計」
    97
    ● フロントエンドには「画面」と「ソフトウェア」、2つ
    の「設計」対象が有る
    ● どちらか一方では不十分だが、画面の「設計」
    に議論が偏っていないか
    ● フロントエンドでも、やはりオブジェクト指向の方
    法論は有力

    View Slide

  98. フロントエンドとアーキテクチャ
    98
    ● Fluxは有力だが、単体ではソフトウェア全体の
    構造を規定できない
    ● フロントエンドでも、クリーンアーキテクチャの方
    法論は有力
    ● フロントエンドは、UI層の中で新たな同心円を形
    作ることになる

    View Slide

  99. 最後に
    99

    View Slide

  100. 「フロントエンド」を誇ろう
    ● 「表示」と「操作」こそ重大な関心事
    ○ サーバーとフロントは、関心事が違うだけ
    ○ それぞれの重要度は所与ではない(システムによる)
    ● 胸を張って 「フロントエンド」に挑もう
    ○ 「JSON色付け係」のような卑下は要らない
    100

    View Slide

  101. ● ドメインは避けられない
    ○ ドメインを分析し理解することは、サーバーサイドだけの仕事ではな

    ○ ドメインの分析・理解は、フロントにおいても重要な仕事
    ● 「設計」も避けられない
    ○ 「表示するだけ」では最早済まない。画面の奥に潜むロジックを飼い
    慣らす術を身に着けよう
    「フロントエンド」に立ち向おう
    101

    View Slide

  102. 参考資料(敬称略)
    102
    ● エリック・エヴァンスのドメイン駆動設計
    ○ Eric Evans(著)今関 剛(監訳)和智 右桂、牧野祐子(訳)
    ● Clean Architecture 達人に学ぶソフトウェアの構造と設計
    ○ Robert C. Martin(著)角 征典、高木 正弘(訳)
    ● 未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明
    ○ Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳)
    ● オブジェクト指向のハードコア
    ○ https://www.zerobase.jp/salon/2019/05/25/hardcore-oo.html
    ○ (2) 哲学
    ○ (3) Smalltalk by @sumim
    ○ (8) GUI by 上野学(@manabuueno)
    ● クライアントアプリの「中心」とは何か
    ○ by @takasek
    ○ https://speakerdeck.com/takasek/20200121-the-center-of-the-client-number-ios-ca

    View Slide

  103. 参考資料(敬称略)
    103
    ● 複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
    ○ by しんぺい(@shinpei0213)
    ○ https://speakerdeck.com/shinpeim/fu-za-najavascriptapurikesiyonnili-tixiang-kautamefalseakit
    ekutiya
    ○ http://techblog.reraku.co.jp/entry/2017/08/08/184313
    ● Almin.js | JavaScriptアーキテクチャ
    ○ by azu(@azu_re)
    ○ https://azu.github.io/slide/2016/child_process_sushi/almin-javascript-architecture.html
    ● CQRS+ES(再)入門
    ○ by かとじゅん(@j5ik2o)
    ○ https://speakerdeck.com/j5ik2o/cqrs-plus-es-zai-ru-men
    ● Facebook の決断:MVCはスケールしない。ならば Flux だ。
    ○ https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/
    ● Vue.js + デザインパターンによるコンポーネント実装
    ○ by @philomagi
    ○ https://speakerdeck.com/tooppoo/vue-dot-js-dezainpatan-niyorukonponentoshi-zhuang-v2
    ○ https://github.com/tooppoo/sample-for-vue-with-design-patterns

    View Slide

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

    View Slide