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

WEBフロントエンドにおける
ソフトウェア設計の考察
1
@Philomagi
2020/02/[email protected] Conference
#ooc_2020 #ooc_c

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

11
本質的な問題ではない

View Slide

12
道具選びが大変なのは事実

View Slide

13
しかし
フロントエンドの難しさ = 道具選び
ではない

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

再掲）「ドメイン」の例
24

View Slide

25
決済したり在庫を減らしたりとか
の計算、結局バックエンドで全部
やるよね

View Slide

26
商品管理とかおすすめ商品の選
出とかも、結局データを出すのは
バックエンドだよね

View Slide

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

View Slide

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

28

View Slide

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

View Slide

再掲）「ドメイン」とは何か
30

View Slide

再掲）「ドメイン」とは何か
31

View Slide

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

View Slide

33

View Slide

34
購入する商品の選択や、実際に
「購入する」という操作は、誰が提
供するのか？

View Slide

35
ユーザーが欲しい商品を見つける、
目の当たりにする方法を、誰が提供
するのか？

View Slide

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

View Slide

「ドメイン」を誰が解決するのか
● バックエンドは計算とデータの整合性を
達成する
● フロントエンドはユーザへの表示と、
ユーザ操作による状態遷移を達成する
37

View Slide

フロントエンドと「ドメイン」の関係
38
フロントエンドは
表示・操作・状態の観点から
ドメインを解決する

View Slide

バックエンドとフロントエンドの違い
39
● バックエンドは整合性という観点からドメイン
の解決に取り組む
● フロントエンドは表示/操作という観点からド
メインの解決に取り組む

View Slide

バックエンドとフロントの違い
40
両者の違いはドメインそのものというより
ドメインの解決にどう取り組むか
どの観点からどんな関心を持つか

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Atomic Design
47

View Slide

48

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

54
Atomic Design のような、
フロントエンドソフトウェア設計の
新たな方法が必要だ！

View Slide

55

View Slide

56
（そうした方法を考えても良いけれど）
有力な方法論が
既に存在している

View Slide

オブジェクト指向
57

View Slide

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

View Slide

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

View Slide

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

View Slide

サンプル
61

View Slide

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

View Slide

63
表示

View Slide

64
操作

View Slide

65
（操作される）状態

View Slide

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

View Slide

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

View Slide

YES
68

View Slide

YES（？）
69

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

82
Clean Architecture (Kindle位置No.3141)

View Slide

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

83

View Slide

84

View Slide

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

View Slide

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

View Slide

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

View Slide

88
重要なのは同心円ではなく
依存性のルール

View Slide

89
重要なのは同心円ではなく
依存性のルール
↓
この「4重の同心円」という
形を守る必要は無い

View Slide

それならば
90

View Slide

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

View Slide

92
UI層
View
Controller
State
State
Action

View Slide

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

View Slide

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

View Slide

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

View Slide

96
そんなのアリ？

View Slide

97

View Slide

98
この同心円の図も、システムの
ほんの一面的な表現でしかない

View Slide

Clean Architecture (Kindle位置No.3141) 99

View Slide

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

View Slide

DBの内部にはDBから見た
デバイスの内部にはデバイスから見た
UIの内部にはUIから見た
内側（コア）と外側（周辺）が
それぞれ有ると考えたほうが自然

View Slide

102

View Slide

103
薄い層なのは単なる図の問題
同心円の図は、システムの一部を切り出し
たモデルでしかない

View Slide

104
UIが外周にあるのは、UI以外のものに焦点
を当てたから
内-外のどこに位置するかは所与ではない
UIに焦点を当てれば、UIが内になる

View Slide

105

View Slide

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

View Slide

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

View Slide

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

View Slide

109

View Slide

110
UI層
View
Controller
State
State
Action

View Slide

111
View

View Slide

112
View
Controller
Controller

View Slide

113
View
Controller
Controller
Model
State

View Slide

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

View Slide

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

View Slide

まとめ
116

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

展望あるいは予想
121

View Slide

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

View Slide

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

View Slide

最後に
124

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

philomagi

More Decks by philomagi

Other Decks in Technology

Featured

Transcript