これは『JSConf.jp おかわり Node学園46時限目』よりt-wadaさんの『「The Clean Architecture」がWebフロントエンドでしっくりこないのは何故か - 制約から考えるアーキテクチャとテスト』の講演を聞いたメモと感想です。
Webフロントエンドでクリーンアーキテクチャがしっくりこない
主題は『クリーンアーキテクチャ（例の同心円）をWebフロントエンドで実装してみたがしっくりこない』という声の正体を探るもの。
例の同心円とは「Clean Architecture」の原則から導かれる具体例の一つである"The Clean Architecture"のバックエンド向けJava実装のこと。
その「形状」だけ真似てWebフロントエンドにもってくることはナンセンスとのこと。
フロントエンドとバックエンドでは追求する品質特性や制約が異なるため、立ち向かう複雑さが異なる。
ソフトウェアアーキテクチャの目的
「Clean Architecture」にはどう書かれているか
『ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。』
「Design it!」にはどう書かれているか
『システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。』
→ 『望まれる品質特性を作るためにどう作るか』ということ。
Design It! ―プログラマーのためのアーキテクティング入門 | Michael Keeling, 島田 浩二 |本 | 通販 | Amazon
アーキテクチャドライバ
品質特性に加えて、制約その他のアーキテクチャ選定に影響を与えるものを識別
- 制約
- 品質特性
- 影響を与える機能要求
- その他の影響を及ぼすもの
品質特性
JIS X 25010の8つの品質特性
ソフトウェア品質を測定可能な特徴として定義したもの
機能適合性: 振る舞い要求（機能要求）に対する品質
その他特性: 非機能要求に対する品質
SQuaRE 品質モデル
SQuaRE 品質モデル: 製品品質の品質特性と品質副特性
つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活用のすすめ | アーカイブ | IPA 独立行政法人 情報処理推進機構
上記品質特性の下に紐づいているそれぞれが品質副特性。
→ The Clean Architectureは保守性に全振りしているが、品質は保守性だけではない。
Webフロントエンドの目指す品質特性
Webフロントエンド版DX Criteria
- ユーザー体験を支える品質
- パフォーマンス
- アクセシビリティ
- セキュリティ
- プライバシー
- デザイン
Webフロントエンド版DX Criteria (v202402)/プロダクトのユーザー体験と変化に適応するチームのためのガイドライン
Webフロントエンドとバックエンドの違い
Webフロントエンドとバックエンドで異なるもの
- UIの重要性
- 実行環境の多様性
- 状態管理の複雑さ
- ビジネスロジックの複雑さ
- パフォーマンスの観点
- 信頼性の観点
- セキュリティの界面
製品品質に品質特性と制約をマッピングすると下記のようになる。
バックエンドで促進したい品質特性
比較する
| 項目 | Webフロントエンド | バックエンド |
|---|---|---|
| 使用性 (Usability) | ユーザー体験（UX）が非常に重要であり、ユーザーにとって使いやすく快適なインターフェースを構築する必要がある。操作性、アクセシビリティに加え、ユーザー操作のエラー・ハンドリングなどのユーザーエラー防止性も重要 | 直接的には影響しない |
| 適応性 (Adaptability) | ユーザーのデバイスやブラウザ上で動作するため、ネットワーク環境やデバイス性能など、実行環境が非常に多様 | サーバー上で動作するため、実行環境は比較的均一。安定したネットワーク環境と豊富なリソースが利用可能 |
| 信頼性 (Reliability) | あえて言うならネットワークの不安定性に伴う障害許容性 | サーバーやデータベース、ネットワークの成熟性（安定性）、可用性、障害許容性（対故障性）、回復性全てが重要 |
| 性能効率性 (Performance) | ページの読み込み速度、レンダリング速度、ユーザー操作への応答速度などが重要 | サーバー側の処理速度、データベースのクエリ速度、サーバー群のスケーラビリティ、ネットワークの帯域幅などが重要 |
| セキュリティ (Security) | クライアント側のセキュリティ対策（XSS、CSRF、データ漏洩対策など）ユーザー入力の検証、プライバシー保護、安全なデータ送信、セキュリティヘッダーの設定など、クライアント側のセキュリティ対策を徹底し、セキュリティリスクを考慮した設計が重要 | サーバー側のセキュリティ対策（認証、認可、データ保護など）が重要 |
保守性
ビジネスロジックの複雑さ
- フロントエンド
- ビジネスロジックの複雑さはバックエンドに比べて比較的単純/ビジネスロジック自体ほとんどない
- バックエンド
- ビジネスロジックの複雑さは高い
- The Clean Architecture, DDDで立ち向かう
状態管理の複雑さ
- フロントエンド
- ユーザー操作や非同期処理によって状態が頻繁に変化し、複雑な状態管理が必要
- コンポーネント指向で立ち向かう
- バックエンド
- 主にDBで整合性を管理し、リクエストごとに状態を処理する
クラス指向OOPとフロントエンド
- なぜWebフロントエンドはクラス指向OOPを避けるようになったのか。
- なぜWebフレームワークはクラスではなく値と関数を使わせようとするのか。
→ パフォーマンスの観点から、関数と値を使った方が高速、かつ最小限の再レンダリングが実現可能
→ 保守性の観点から、遅延束縛のクラスよりもESMの方がバンドルサイズ削減に向いている
パフォーマンス
- Webフロントエンドのフレームワークはstateやpropsが変更された際に変更された部分のみを効率的に再レンダリングすることで、パフォーマンスを最適化している。
- 変更の検知において、値の比較はクラスのインスタンス比較よりも高速かつ容易。
- フレームワークは変更された部分のみを正確に特定し、最小限の再レンダリングで済ませられる。
保守性（モジュール性と資源最適性）
- バンドルサイズを削減するためにクラスよりモジュール(ESM)の方が向いている。
- クラスは遅延束縛 = 実行時まで削減できるクラスがわからないためバンドルサイズ削減に向かない
- 設計上の決定は先送りするが、実行上の決定は先送りすると不利なのがWebフロントエンド
- クラスは遅延束縛 = 実行時まで削減できるクラスがわからないためバンドルサイズ削減に向かない
まとめ
- Webフロントエンドでクリーンアーキテクチャがしっくりこないのは以下の二点
- Clean Architectureで語っている原則を元に作成したJava実装で促進している品質が保守性であり、特にドメインの複雑性に立ち向かうものであるため。
- "The Clean Architecture"はJava実装であるためクラスベースで語られているが、Webフロントエンドは関数と値を使用したコンポーネント指向が主流であるため、言語・FW仕様と噛み合わない。
- Webフロントエンドが立ち向かうべき複雑性は状態管理である。
普段バックエンドの開発が主なのでなぜフロントエンドはコンポーネント指向に向かっているのかよく理解していなかったため、非常に勉強になった。
バックエンドとフロントエンドでは立ち向かう複雑さが異なるという点が特にしっくりきた。
遅延束縛や決定の先送りといったことについて考えたことがなかったので今後インプットを増やしていきたい。