TL;DR
- ソフトウェアアーキテクチャの目的は望まれる品質特性を促進することであり、Web フロントエンドとバックエンドでは促進したい品質特性も制約も異なる。
- 書籍『Clean Architecture』の原則は Web フロントエンドにも活かせるが、第 22 章の同心円（“The Clean Architecture”）のバックエンド向け Java 実装の形だけを真似てもしっくりこないのは当たり前である。
- React などは、保守性とパフォーマンスを両立するために、OOP から FP へのスタイル変更を促している。
内容
ソフトウェアアーキテクチャの目的
『Design It!』の定義では、ソフトウェアアーキテクチャとは、望まれる品質特性などを促進するためにソフトウェアをどう構成するかについての重要な設計判断の集まりである。アーキテクチャ構造を選ぶことは、促進したい品質特性を選ぶことでもある。アーキテクチャに影響を与えるもの（アーキテクチャドライバ）には、品質特性のほかに制約がある。制約とは、変更できない設計判断のことである。
Web フロントエンドの品質特性と制約
Web フロントエンドには、多様なデバイスとブラウザ、不安定なネットワーク、XSS や CSRF といったクライアント側のセキュリティリスク、検索順位に影響する Core Web Vitals、事実上 JavaScript しか選べない言語といった制約がある。品質特性で見ても、Web フロントエンドでは使用性、実行環境への適応性、ページの読み込みや操作への応答の速さが重要になる。バックエンドでは信頼性やサーバ側の性能が重要になる。
保守性では、立ち向かう複雑さが違う。バックエンドはビジネスロジックが複雑になりやすく、DDD や “The Clean Architecture” はそれと戦う技術である。Web フロントエンドはビジネスロジックが比較的単純な一方、ユーザー操作や非同期処理で状態が頻繁に変わるので、状態管理が複雑になる。この複雑さと戦う技術がコンポーネント指向である。
“The Clean Architecture” の功罪
書籍『Clean Architecture』は設計の原則を示した本で、同心円の図はその第 22 章に出てくる一例にすぎず、直後の実例は Java で書かれたバックエンドである。書籍の内容は素晴らしいが、同心円が「クリーンアーキテクチャ」という名前で独り歩きしてしまった。
なぜ React などは関数と値を使うのか
React などのコンポーネント指向フレームワークは、データが変わった部分だけを再レンダリングしてパフォーマンスを上げようとする。変更後のデータを作るとき、一部だけを書き換えたコピーを作るのは、インスタンスより plain object のほうが容易である。また、ESM は静的解析できるが、クラスは構造上削りにくく継承もある。そのため、ESM と純粋関数とイミュータブルな値で書けば、使われていないコードをバンドルから削りやすい。
発表では、React などのフレームワークの制約が OOP の価値観とぶつかり、OOP に慣れたプログラマにスタイルと価値観の変更を迫るとしている。挙げられていたのは、「隠さない、先送りしない」、遅延束縛よりも静的解析しやすさ、状態のカプセル化よりもイミュータブルな値である。継承できることは解析に不利に働き、設計上の決定は先送りしてもよいが、実行時まで決定を先送りすると不利になる。Rust が安全性とパフォーマンスの両立のためにスタイルの変更を促したのと同じく、React などは保守性とパフォーマンスの両立のために OOP から FP へのスタイル変更を促していると考えられる。
キーワード
- クリーンアーキテクチャ
- ソフトウェアアーキテクチャ
- 品質特性
- アーキテクチャドライバ
- ISO/IEC 25010
- Core Web Vitals
- XSS
- CSRF
- ドメイン駆動設計
- React
- 関数型プログラミング