Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

主張したいこと ● 現代のフロントエンドは単に「画面表示」と言えるほ ど単純ではない ● 「ロジック」も「ドメイン」も、フロントエンドには存在す る ● 「画面設計」だけでなく「ソフトウェア設計」も、フロン トエンドには必要 6

Slide 7

Slide 7 text

反論したいこと ❌ フロントエンドは表示して終わり ❌ 表示だけなので、「ドメイン」も「ロジック」も存在しな い ❌ フロントエンドの「設計」と言えば「画面設計」（で終 わる議論） 7

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

フロントエンドのドメイン 27 操作（「した」） と 表示（画面に表す）

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

オブジェクト指向 37

Slide 38

Slide 38 text

再掲）フロントエンドのドメイン 38 操作（「した」） と 表示（画面に表す）

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

オブジェクト指向をどのように用いるか？ フロントエンドのドメインである 「操作」と「表示」に注目する 40 ↓ 「操作」と「表示」に関わる要素を オブジェクトとして抽出する

Slide 41

Slide 41 text

サンプル 41

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

複雑な「操作ルール」を考える 53 （有る種の）MVC

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

YES 56

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

他のアーキテクチャ 67

Slide 68

Slide 68 text

68 Clean Architecture (Kindle位置No.3141)

Slide 69

Slide 69 text

フロントエンドで クリーンアーキテクチャ（CA)？ 69

Slide 70

Slide 70 text

70 Clean Architecture (Kindle位置No.3141)

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

75 フロントにおけるCAの意義 重要なのは同心円ではなく 依存性のルール ↓ この「4重の同心円」という 形を守る必要は無い

Slide 76

Slide 76 text

それならば 76

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Clean Architecture (Kindle位置No.3141) 81

Slide 82

Slide 82 text

Clean Architecture (Kindle位置No.3141) 82 デバイス・DB・ウェブ・UIが外周に在るのは、 それらに積極的に関心を持たない立場から システムを見ているから ↓ 「外周のものは重視せず、中央のものを重視する」とい う表明に過ぎない。 内外の関係は、この一通りではない。

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

84

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

86

Slide 87

Slide 87 text

87

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

89 UI層 View Controller Model State Action

Slide 90

Slide 90 text

サンプルで考える 90

Slide 91

Slide 91 text

サンプルで考える 91 View

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

まとめ 95

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

最後に 99

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

参考資料(敬称略) 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

Slide 103

Slide 103 text

参考資料(敬称略) 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

Slide 104

Slide 104 text

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