[WIP] Webフロントエンドにクリーンアーキテクチャは導入できるのか
黄昏@t_wada氏の資料を参考に、表題の議論を思考整理します。
先に結論を言うと、"The Clean Architecture"はWebフロントエンドに導入することはできないが、Webフロントエンド向けのアーキテクチャの形状は存在すると個人的に考えています。
ソフトウェアアーキテクチャの解釈
ソフトウェアシステムのアーキテクチャは、それを構築した人がシステムに与えた「形状」である。その形状を生み出すためには、システムをコンポーネントに分割し、コンポーネントをうまく配置して、コンポーネントが相互に通信できるようにする必要がある。
アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すことである。
by『Clean Architecture』P.148
@unclebobmartin氏(通称 ボブおじさん) は、自身の書籍である『Clean Architecture』にて、ソフトウェアシステムのアーキテクチャについて上記のように言及しています。
ボブおじさんの言うソフトウェアアーキテクチャは、システムをコンポーネントという単位で細分化して、それらをうまく組み合わせてDevOpsサイクルを効率的に回しやすくするための戦略であり、コンポーネントはカスタマイズしやすい状態に保つ必要があることが伝わります。
ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。
by 『Clean Architecture』P.34
また、ソフトウェアアーキテクチャは、”労力を必要最小限に抑える”ためにあるとも解釈できそうです。
システムのソフトウェアアーキテクチャとは、望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかということに対する、重要な設計判断が集まったものだ。
by 『Design It!』P.8品質特性とは、ソフトウェアシステムの外部から見える特性とそのシステムの運用に対する期待を表す。品質特性は、システムが何らかのアクションをどれだけうまく行うかを定義する。システムのこれらの「〜性」は、「品質要求」と呼ばれることもある。
by 『Design It!』P.65~66アーキテクチャ構造を選択するということは、ソフトウェアシステムで促進したい品質特性を選択しているということだ。
ソフトウェアアーキテクチャについて考える際には、さまざまな関心事に注意を引かれる。そんな中で、私たちには、自分たちが望む品質特性を支援するソフトウェアシステムを設計することが求められる。
by 『Design It!』P.12品質特性を促進するとは、それがソフトウェアシステムの中に現れるよう働きかけるということだ。アーキテクチャがうまく構成されている場合、ステークホルダーの求める品質特性は向上する。そして、求めていない品質特性は控えめに取り扱われるか、または、取り除かれる。
by 『Design It!』P.8
対して、@michaelkeeling氏の著書『Design It!』では上記のように語られています。
ボブおじさんの説明と比較して、「品質特性」という単語を用いてより具体かつ定量的な部分で言及しており、サービス指向の考えに近い印象を受けました。
@michaelkeeling氏の言うソフトウェアアーキテクチャは、特定の要素(品質特性) を重要視する場合のソフトウェア構成の設計判断をまとめたものだと伝わります。
つまり、「促進したい品質特性を選定する＝アーキテクチャ構成を選択する」とも捉えられます。
もちろん、すべての品質特性を促進できるのが理想的ですが、ユーザー側から直接的に要求される品質特性と、システム側(バックエンド) で要求される品質特性が異なる点や、技術的な要素(フレームワークや言語など) による実現可能性、品質特性間のトレードオフの問題などを考慮すると、すべてを促進することは不可能に感じます。
品質特性とは、ソフトウェア品質を測定可能な特徴として定義したもの。
機能適合性: 振る舞い要求（機能要求）に対する品質
その他特性: 非機能要求に対する品質
by 『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』
そもそも、「品質特性」については国際規格が定まっており、ISO/IEC 25010(元祖ISO/IEC 9126の改良版) は、ソフトウェア品質の評価に関する国際規格として知られ、8の品質特性と31の品質副特性に分類されます。
品質特性 - つながる世界のソフトウェア品質ガイド by IPA
品質特性の詳細については、奥が深そうなのでまたの機会にまとめます。
ここでは、「ソフトウェア品質の基準となるもの」という解釈で問題ないでしょう。
Webフロントエンドに求められる品質特性
品質特性が何かを把握したところで、本題であるWebフロントエンドで求められる品質特性を整理します。
@t_wada氏の資料では、『Webフロントエンド版DX Criteria』で推奨されている品質を紹介していました。
同氏がWebフロントエンド領域における促進したい品質特性として挙げていたのは以下の項目になります。(『つながる世界のソフトウェア品質ガイド - IPA』参照)
- 性能効率性(時間効率性)
- 使用性
- セキュリティ
- 保守性
Webフロントエンドで促進したい品質特性
ここは、人によって解釈が分かれそうですが、『Webフロントエンド版DX Criteria』で定義されている範囲内であれば妥当性を感じます。
つまり、品質特性の観点においては、Webフロントエンドにおける理想的なソフトウェアアーキテクチャとは、「性能効率性(時間効率性)」「使用性」「セキュリティ」「保守性」を促進するためのソフトウェア構成であると解釈できそうです。
アーキテクチャドライバ
ここまで、@michaelkeeling氏の著書『Design It!』の解釈をもとにソフトウェアアーキテクチャについて言及しましたが、品質特性以外にもアーキテクチャを選定するにあたり、重要な指標は存在します。
@tyonekubo氏の書籍『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』では、アーキテクチャの構造を決定する要素として、「アーキテクチャドライバ」を紹介しています。
アーキテクチャドライバは以下の4つから構成されるとのことです。
- 制約(ビジネス/技術)
- 品質特性
- 影響を与える機能要求
- その他の影響を及ぼすもの
アーキテクチャドライバの構成
以降、制約(ビジネス/技術) について深掘ります。
制約(ビジネス/技術)
制約とは、選んだか与えられたかによらない、変更できない設計判断のことをいう。
大半のソフトウェアシステムは、多少の制約を持っているものだ。すべての制約は選択を制限するものだが、適切に選択された制約は問題を単純化し、満足のいくアーキテクチャ設計をずっと容易にする。逆に、制約は、要求を満たせないほど選択肢を厳しく制限することで、アーキテクトにとって生き地獄を作り出すこともある。
by 『Design It!』P.64
@michaelkeeling氏は、著書『Design It!』にて上記の定義をしています。
前半にて、「制約とは、選んだか与えられたかによらない、変更できない設計判断」と言及している一方で、後にて「適切に"選択された"制約は...」と述べています。
一見、矛盾しているように思えますが、制約が変更できないのは、その時点の設計判断として確定されている場合のみの話であり、アーキテクチャ構成などの技術的な要素をうまく選定することで、課される制約もある程度はコントロール可能だと考えます。
つまり、「制約は変更できない設計判断」というのは、一度受け入れた制約の性質を表しているのであって、設計プロセスの中で「どの制約を受け入れるか選ぶ」ことは可能です。むしろ、良いアーキテクトほど「適切な制約を選び、問題を単純化する」能力が求められるとも言えそうですね。
Webフロントエンドにおける制約
自由自在に制約を選択できれば嬉しい話ですが、現実的にそう簡単にはいきません。
Webフロントエンドにおいては、ブラウザ、ネットワーク、SEOなどの制約が付き纏います。
@t_wada氏は、資料にて以下の制約を挙げています。
- デバイスとブラウザの制約
- さまざまなデバイス(スマートフォン、タブレット、PCなど) やブラウザ(Chrome、Firefox、Safariなど) で動作する必要がある
- ネットワークの制約
- ネットワークの遅延や不安定性など、通信環境に起因する問題がある
- セキュリティの制約
- XSSやCSRFなど、クライアントサイドのセキュリティリスクがある
- SEOの制約(Core Web Vitals)
- パフォーマンス改善は少し前までは非機能要件だったが、今では実利に伴う重要な要素となってきており、サイトの読み込み速度が遅いと検索順位を下げられてしまう
- プログラミング言語の制約
- 現実的にはJavaScript(TypeScript含む) 一択の状態
さらに、SEO(Core Web Vitals) による制約は多岐に渡ります。
同氏はWebフロントエンドの制約により生じる促進すべき品質特性を以下のように紹介しています。
Webフロントエンドの制約により生じる促進すべき品質特性
前述したアーキテクチャドライバの構成要素として、「品質特性」「制約」...と紹介されていたので、互いに独立した要素と捉えていたのですが、少なくとも制約から意識すべき新たな品質特性が生じるケースも存在するため、全くの無関係という訳ではなさそうです。
結論として、Webフロントエンドとその制約に関係する品質特性は以下のようになりました。
Webフロントエンドとその制約に関係する品質特性
もちろん、プロジェクトやビジネスサイドの要件によって必ずしもこのような品質特性には限らないと思いますが、多くはこの形に近いものが要求されると考えます。
Webフロントエンドとバックエンドの違い
ここまで、アーキテクチャの構成要素について説明しましたが、ここからは、本題であるWebフロントエンドにクリーンアーキテクチャが導入できるのかについて考えます。
そのためには、Webフロントエンドとバックエンドの違いについて言及する必要があります。
@t_wada氏は資料にて、品質特性(制約含む) の面から両者を比較していました。
| 品質特性 | Webフロントエンド | バックエンド |
|---|---|---|
| 使用性 | UXが非常に重要であり、ユーザーにとって使いやすく快適なインターフェースを構築する必要がある。操作性、アクセシビリティに加え、ユーザー操作のエラーハンドリングなどのユーザーエラー防止性も重要 | 直接的には影響しない |
| 適応性 | ユーザーのデバイスやブラウザ上で動作するため、ネットワーク環境やデバイス性能など、実行環境が非常に多様 | サーバー上で動作するため、実行環境は比較的均一。安定したネットワーク環境と豊富なリソースが利用可能 |
| 信頼性 | あえて言うならネットワークの不安定性に伴う障害許容性が必要 | サーバーやデータベース、ネットワークの成熟性(安定性) 、可用性、障害許容性(対故障性) 、回復性全てが重要 |
| 性能効率性 | ページの読み込み速度、レンダリング速度、ユーザー操作への応答速度などが重要 | サーバー側の処理速度、データベースのクエリ速度、サーバー群のスケーラビリティ、ネットワークの帯域幅などが重要 |
| セキュリティ | クライアント側のセキュリティ対策(XSS、CSRF、データ漏洩対策など) ユーザー入力の検証、プライバシー保護、安全なデータ送信、セキュリティヘッダーの設定など、クライアント側のセキュリティ対策を徹底し、セキュリティリスクを考慮した設計が重要 | サーバー側のセキュリティ対策(認証、認可、データ保護など) が重要 |
また、同氏は保守性が複雑化している領域が異なることも強調しています。
| Webフロントエンド | バックエンド | |
|---|---|---|
| ビジネスロジックの複雑さ | バックエンドに比べてビジネスロジックは比較的単純、あるいはほぼ無い場合もある | ビジネスロジックが非常に複雑になる場合がある |
| 状態管理の複雑さ | ユーザー操作や非同期処理によって状態が頻繁に変化し、複雑な状態管理が必要 | 主にデータベースで整合性を管理し、リクエストごとに状態を処理する |
両者の複雑さに対してのそれぞれの戦略
Webフロントエンドは、コンポーネント指向という武器でフロントエンド特有の状態管理の複雑さと戦い、バックエンドは、DDD、"The" Clean Architectureという武器でビジネスロジックの複雑さと戦うイメージです。
"The" Clean Architectureの誤解
資料でも触れられている通り、世間のクリーンアーキテクチャに対する認識が人によって異なっているケースが多く見られます。
そもそも、"Clean Architecture"というのはボブおじさんの書籍で提唱された設計アプローチの名称であり、"The Clean Architecture"というのはその書籍の中で具体例の一つとして挙げられている例の同心円のことを指します。
The Clean Architecture(例の同心円)
つまりは、必ずしもこの形に整理する必要性はなく、これはあくまでボブおじさんが書籍の中でバックエンド向けのJava実装で挙げた実例だと解釈するのが賢明です。
W.I.P.