WEBフロントエンドにおけるソフトウェア設計の考察 / Consideration of software design in WEB front end

by philomagi

Slide 1

Slide 1 text

WEBフロントエンドにおけるソフトウェア設計の考察 1 @Philomagi 2020/02/16@Object-Oriented Conference #ooc_2020 #ooc_c

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

「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 21

Slide 22

Slide 22 text

「フロントエンドにドメインは無い」か？ 22

Slide 23

Slide 23 text

「フロントエンドにドメインは無い」か？ ● フロントエンドの責務 = 画面の表示 ● いわゆる「業務ロジック」「ビジネスロジック」は、バックエンドで処理されるのが一般 → 「フロントは結局表示しかしないのだから、「ドメイン」は無い」という言説 23

Slide 24

Slide 24 text

再掲）「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 24

Slide 25

Slide 25 text

再掲）「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 25 決済したり在庫を減らしたりとかの計算、結局バックエンドで全部やるよね

Slide 26

Slide 26 text

再掲）「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 26 商品管理とかおすすめ商品の選出とかも、結局データを出すのはバックエンドだよね

Slide 27

Slide 27 text

「フロントエンドにドメインは無い」 ● 「フロントエンドって、詰まるところはサーバーが計算してくれた内容を綺麗に表示するだけだよね」 ● 「業務ロジックとかビジネスロジックとか、そういうロジックは全部バックエンドに集められて、フロントエンドには残らないよね」 ● 「じゃあ、フロントエンドにドメインなんてものは無いよね」 ● 「じゃあ、フロントエンドって、結局表示して終わりだよね」 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

フロントエンドとドメインの関係を考える 29

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

ソフトウェアと「ドメイン」 ● 「ドメイン」＝「ユーザの何らかの活動や関心」 ● フロントエンドもまたソフトウェアである以上、「何らかの活動や関心」に関わるはず ○ 「ドメインが無い = それらに一切関わらない」なら、それは総容量0KB、何一つ処理をしないソフトウェアのはず 32

Slide 33

Slide 33 text

再掲）「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 33

Slide 34

Slide 34 text

再掲）「ドメイン」の例例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう 34 購入する商品の選択や、実際に「購入する」という操作は、誰が提供するのか？

Slide 35

Slide 35 text

例えばECサイトなら ● 商品を購入すること ● （ユーザーは）欲しい商品に到達すること ● （運営は）売りたい商品に到達させることあたりが、ドメインの一部として考えられそう再掲）「ドメイン」の例 35 ユーザーが欲しい商品を見つける、目の当たりにする方法を、誰が提供するのか？

Slide 36

Slide 36 text

「ドメイン」を誰が解決するのかドメインの解決は 1つ以上のソフトウェアによって達成される 36

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

Slide 42

Slide 42 text

フロントエンドの関心事 42 ユーザーが「した」と思ったことを画面に表すこと

Slide 43

Slide 43 text

フロントエンドの関心事 43 操作（「した」）表示（画面に表す）

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Atomic Design 47

Slide 48

Slide 48 text

Slide 49

Slide 49 text

49 Atomic Design Atomic Designは、どんな単位でUIをコンポーネント化すればよいかを示してくれるとてもシンプルなフレームワークです。（中略） Brad Frost氏は、従来の画面ごとにUIデザインを作っていくという考え方ではなく、コンポーネントのしくみを設計することがWebをデザイン（設計）することだと考えています。「Atomic Design 堅牢で使いやすいUIを効率良く設計する」 3-1. Atomic Designとは注：Brad FrostはAtomic Designの考案者

Slide 50

Slide 50 text

50 Atomic Design Atomic Designは、どんな単位でUIをコンポーネント化すればよいかを示してくれるとてもシンプルなフレームワークです。（中略） Brad Frost氏は、従来の画面ごとにUIデザインを作っていくという考え方ではなく、コンポーネントのしくみを設計することがWebをデザイン（設計）することだと考えています。「Atomic Design 堅牢で使いやすいUIを効率良く設計する」 3-1. Atomic Designとは注：Brad FrostはAtomic Designの考案者

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

オブジェクト指向 57

Slide 58

Slide 58 text

再掲）フロントエンドの関心事 58 操作（「した」）表示（画面に表す）

Slide 59

Slide 59 text

オブジェクト指向をどのように用いるか？フロントエンドの関心事である操作・表示に注目する 59

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

サンプル 61

Slide 62

Slide 62 text

62 https://github.com/tooppoo/sample-for-vue-with-design-patterns http://localhost:8080/strategy-pattern

Slide 63

Slide 63 text

63 表示

Slide 64

Slide 64 text

64 操作

Slide 65

Slide 65 text

65 （操作される）状態

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

要するに「ちゃんと設計しよう」って言ってるだけじゃない？ 67

Slide 68

Slide 68 text

YES 68

Slide 69

Slide 69 text

YES（？） 69

Slide 70

Slide 70 text

「ちゃんと」って？「設計」って？ 70

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

ここでの「ちゃんと設計」すること 72 ● 画面だけでなく、画面の奥のソフトウェアに対しても設計を行う ● 必要なら、画面と設計、それぞれに適切な方法論を用いる ○ 例) 画面ではAtomic Designを、ソフトウェアではオブジェクト指向を用いる

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

有力だと考えているのが 81

Slide 82

Slide 82 text

82 Clean Architecture (Kindle位置No.3141)

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

84 Clean Architecture (Kindle位置No.3141)

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

それならば 90

Slide 91

Slide 91 text

注：ここからオレオレなクリーンアーキテクチャ論 91

Slide 92

Slide 92 text

92 UI層 View Controller State State Action

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

96 そんなのアリ？

Slide 97

Slide 97 text

97 Clean Architecture (Kindle位置No.3141)

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

Clean Architecture (Kindle位置No.3141) 99

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

こんな薄い層でできるの？外周でやって意味有るの？ 103 薄い層なのは単なる図の問題同心円の図は、システムの一部を切り出したモデルでしかない

Slide 104

Slide 104 text

こんな薄い層でできるの？外周でやって意味有るの？ 104 UIが外周にあるのは、UI以外のものに焦点を当てたから内-外のどこに位置するかは所与ではない UIに焦点を当てれば、UIが内になる

Slide 105

Slide 105 text

105

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

107 クリーンアーキテクチャのフラクタル構造

Slide 108

Slide 108 text

108 サンプルに当てはめると？

Slide 109

Slide 109 text

109

Slide 110

Slide 110 text

110 UI層 View Controller State State Action

Slide 111

Slide 111 text

111 View

Slide 112

Slide 112 text

112 View Controller Controller

Slide 113

Slide 113 text

113 View Controller Controller Model State

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

まとめ 116

Slide 117

Slide 117 text

現代フロントエンドの難しさ 117 ● 現代のUIはよりリッチ/インタラクティブな動作が求められている ● それに伴い「操作」と「表示」が複雑化している ● 現代フロントエンドの難しさは、この2点をいかに管理するか

Slide 118

Slide 118 text

フロントエンドとドメイン 118 ● UIを提供するシステムのドメインが、フロントエンドのドメイン ● フロントエンドは、「操作」と「状態」を主な関心事としてドメインの課題を解決する ● ユーザーが「した」と思ったことを現実にする

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

展望あるいは予想 121

Slide 122

Slide 122 text

展望あるいは予想 122 ● 「ユーザーイリュージョン」への接続 ○ フロントの関心＝「ユーザーが『した』と思ったことを現実にする」という整理は、「ユーザーイリュージョン」という視点へつながりそう？（ cf. 「MVCとは何か」）。 ○ 実装パターンではなく、パタン・ランゲージとしての MVCとの接続？（cf. The Model-View-Controller (MVC)Its Past and Present） ■ 「ユーザーが『した』と思ったことを現実にする」は「ユーザーのメンタルモデルを実装する」につながるか？ ■ 操作と表示を改めて Viewから隔離することで、 Viewの「民主化」は成るか？ ● オブジェクト指向ユーザーインターフェース（OOUI）との関連 ○ 「フロントエンドソフトウェアの設計」と相性が良いように感じた。 ○ むしろ、今回の議論の行き着くところは OOUIなのかもしれない。

Slide 123

Slide 123 text

展望あるいは予想 123 ● フロントエンドDDDの検証 ○ フロントエンドはサーバーとは別の形でドメインと関わる。 ○ それならば、フロントエンドでの DDDも理論上可能なはず。 ■ 一方で、フロントエンドのドメインとの関連の仕方はことなる以上、フロントエンドにおける「ドメインモデル」の対象も変わってきそう ■ フロントエンドにとってのドメインモデルは「ユーザーのメンタルモデル」？ ○ フロントエンドDDDにおける特殊性・一般性・要件を言語化する。 ● CQRS(+ES)としてのFluxアーキテクチャ再分析 ○ フロントエンドCQRS(+ES)という視点は有力に感じた。 ○ 具体的な活用方法や活用箇所を言語化する。

Slide 124

Slide 124 text

最後に 124

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

● ドメインは避けられない ○ ドメインを分析し理解することは、バックエンドだけの仕事ではない ○ ドメインの分析・理解は、システム開発全体にとって重要 ● 「設計」も避けられない ○ 「表示するだけ」では最早済まない。画面の奥に潜むロジックを飼い慣らす術を身につけよう最後に 126

Slide 127

Slide 127 text

誇りを持ってフロントエンドに立ち向かう最後に 127

Slide 128

Slide 128 text

参考資料(敬称略) 128 ● エリック・エヴァンスのドメイン駆動設計 ○ 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 129

Slide 129 text

参考資料(敬称略) 129 ● 複雑な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-ﬂux/ ● 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 130

Slide 130 text

参考資料(敬称略) 130 ● モデルとは何であって、何でないのか ○ by 末並晃（@a_suenami） ○ https://speakerdeck.com/a_suenami/moderutohahe-deatute-he-denaifalseka-number-kichijojipm ○ https://a-suenami.hatenablog.com/entry/2019/08/05/084814 ● atomic design ○ by brad frost ○ https://bradfrost.com/blog/post/atomic-web-design/ ● Atomic Design 〜堅牢で使いやすいUIを効率よく設計する ○ 五藤佑典 ● MVCとはなにか ○ by 天重誠二（@tenjuu99） ○ https://speakerdeck.com/tenjuu99/what-mvc-is ○ https://note.com/tenjuu99/n/n0232ccd1089d ○ https://note.com/tenjuu99/n/nbbb4b273676d ● The Model-View-Controller (MVC)Its Past and Present ○ Trygve Reenskaug ○ http://folk.uio.no/trygver/2003/javazone-jaoo/MVC_pattern.pdf

Slide 131

Slide 131 text

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