【ITニュース解説】Part 3 — Advanced Frontend Engineering Patterns

Webアプリケーション、特にフロントエンドの開発では、時間が経つにつれてコードが複雑になり、管理が難しくなるという問題がしばしば起こる。この問題に対処するため、アプリケーションのコードを役割に応じて「ドメイン層」「アプリケーション層」「インフラストラクチャ層」「プレゼンテーション層」といった独立した層に分割する方法が有効である。しかし、コードをきれいに分離し、抽象的なインターフェースを使っても、実際の運用ではいくつかの課題に直面する。例えば、これらの部品をプログラム実行時にどうやって適切に組み合わせるのか、また、データのキャッシュや非同期処理、そして素早いテスト実行といった複雑な問題を、せっかく作ったアーキテクチャの境界を崩さずにどう解決するのか、といった点である。ここでは、これらの課題を解決するための高度な設計パターンについて具体的に説明する。

まず、各層のコードがどのように連携するかを理解することが重要だ。フロントエンドのユーザーインターフェース（プレゼンテーション層）は、ユーザーの操作に応じて「ViewModelフック」というカスタムフックを呼び出す。このフックは、直接具体的な処理を実装するのではなく、「IoCコンテナ」と呼ばれる仕組みを使って、アプリケーション層にある「コマンドハンドラー」や「クエリハンドラー」といった処理の実行役を取得する。アプリケーション層のハンドラーは、「ポート」と呼ばれる抽象的なインターフェースを実装しており、実際のデータ操作や外部サービスとの連携は、このポートを通じて間接的に行われる。インフラストラクチャ層は、このポートの具体的な実装（アダプター）を提供する。例えば、ICartRepositoryというショッピングカートのデータを操作するポートに対して、ApiCartRepositoryというWeb APIを通じてデータを取得・保存する具体的なアダプターが作られる。ここで重要なのは、「依存性逆転の原則」だ。インフラストラクチャ層がアプリケーション層で定義されたポートを実装することで、上位層（アプリケーション層）が下位層（インフラストラクチャ層）に直接依存せず、柔軟な設計が可能になる。

このような層構造を維持しつつ、各部品を柔軟に組み合わせるための最初のパターンが「依存性注入（Dependency Injection）」と「コンポジションルート（Composition Root）」だ。アプリケーションのコードやカスタムフックの中で、new ApiCartRepository()のようにインフラストラクチャ層の具体的な実装を直接生成することは避けるべきである。なぜなら、これは特定のインフラにコードが強く結びつき、「密結合」と呼ばれる状態を生み出し、テストしにくくなるからだ。代わりに、「制御の反転（Inversion of Control: IoC）」という考え方を利用し、InversifyJSのようなライブラリを使って、プログラム実行時に必要な依存関係を動的に解決する。

具体的には、まずアプリケーションのポートやサービスに対して、Symbol.forを使って一意の識別子（シンボル）を定義する。これにより、どのサービスが必要かを型安全に指定できるようになる。そして、「コンポジションルート」と呼ばれるアプリケーション内でただ一つの場所で、これらのシンボルと具体的な実装を紐づける（バインディングする）。このコンポジションルートだけが、具体的なインフラストラクチャアダプターをインポートし、インスタンスを生成することを許される。この際、例えば「production（本番環境）」、「test（テスト環境）」、「ssr（サーバーサイドレンダリング環境）」といった実行環境に応じて、ICartRepositoryに対して「Web APIと通信する実装」を割り当てたり、「メモリ上にデータを保持するテスト用の実装」を割り当てたりと、柔軟に切り替えることが可能になる。このようにすることで、環境が変わってもアプリケーションのビジネスロジックは一切変更する必要がなくなる。さらに、Reactアプリケーション内でこれらの依存関係を利用するためには、InversifyJSに直接依存しないよう、DependencyInjectionProviderというReactコンテキストとuseDependencyというカスタムフックを使って、必要なサービスをコンポーネントに提供する。これにより、UIコンポーネントやビジネスルールに影響を与えることなく、裏側のインフラを簡単に交換できるようになる。

次に、「タグベースのキャッシュ無効化」というパターンについて説明する。多くのフロントエンドアプリケーションでは、ローカルに保持しているUIの状態を、データが更新されたときに自動的に最新の状態に保つことや、不必要なネットワーク通信を避けることが難しい問題である。この問題を解決するため、アプリケーションの「クエリハンドラー」（データを取得する役割の部品）は、取得したデータに「タグ」というメタデータを付与する。例えば、カートの情報を取得するクエリハンドラーは、「cart」や「pricing」といったタグを持つ。一方で、「コマンドハンドラー」（データを変更する役割の部品）がデータの更新に成功すると、関連するタグを無効化するよう指示を出す。

このキャッシュ管理を行うのが「インフラストラクチャキャッシュマネージャー」だ。このマネージャーは、データを保存する際にそのデータに関連するタグも一緒に保存する。そして、特定のタグが無効化されるべきだと指示されると、そのタグを持つキャッシュされたデータを削除する。さらに、このキャッシュマネージャーは、特定のタグの無効化イベントを購読しているUIコンポーネント（正確にはカスタムフック）に対して通知を送る。

Reactのコンポーネントは、「useCartSummaryViewModel」のようなカスタムフックを通じて、これらのクエリハンドラーやキャッシュマネージャーを利用する。このカスタムフックは、まずキャッシュに目的のデータがあるかを確認し、あればそれを利用してUIを更新する。なければクエリハンドラーを通じてデータをフェッチし、キャッシュに保存する際にそのタグも登録する。さらに重要なのは、このフックはクエリハンドラーが持つキャッシュタグに対して購読（subscribe）する点だ。これにより、他の部分でデータが更新され、例えば「cart」タグが無効化されたという通知が来ると、このフックは自動的にデータを再フェッチし、UIを最新の状態に保つことができる。結果として、開発者は複数のReactコンポーネント間で手動で状態を同期させる手間から解放され、UIは常にデータソースと同期した状態を保てる。

そして、最後に「高速な分離テスト戦略」についてだ。ドメインのルールやユースケースのロジックをReactやブラウザのAPIから切り離すことの大きな利点は、テストの実行速度と信頼性が劇的に向上することだ。テストは大きく二つの種類に分けられる。

一つは、「純粋なドメインユニットテスト」だ。ドメイン層にあるエンティティや値オブジェクトは、純粋なTypeScriptのクラスとして設計されているため、外部のライブラリやフレームワークに依存しない。そのため、テスト時にjest.fn()のようなモック（擬似オブジェクト）を作成したり、Webブラウザの環境を模倣するJSDOMを使ったり、Reactのテストユーティリティを使う必要がない。これにより、非常に高速に、かつ安定してテストを実行できる。例えば、ショッピングカートに同じ商品を複数追加した場合の合計数量や金額の計算、異なる通貨を組み合わせようとした場合のエラー発生などを、純粋なロジックとして直接テストできる。

もう一つは、「インメモリフェイクを使ったユースケースハンドラーテスト」である。これは、Web APIのような外部のネットワークリソースをモックする代わりに、テスト専用に作られた「インメモリフェイクアダプター」をIoCコンテナに組み込んでテストする方法だ。例えば、AddItemToCartCommandHandlerのような、カートに商品を追加する処理のテストでは、実際のデータベースやWeb APIの代わりに、メモリ上でデータを保持・操作する偽の（フェイクの）リポジトリをコンポジションルートでバインドする。テストコードは、このフェイクリポジトリに初期状態を設定し、コマンドハンドラーを実行し、その後フェイクリポジトリの状態を検証することで、ビジネスロジックが正しく動作するかを確認する。これらのテストは、JSDOMや実際のHTTP通信のオーバーヘッドなしにNode.js環境で実行されるため、何百ものビジネスロジックのシナリオが瞬時に完了し、開発プロセス全体の高速化と、テストの不安定さの解消に大きく貢献する。

これらの高度なエンジニアリングパターンは、それぞれ異なる問題を解決し、堅牢で保守性の高いフロントエンドアプリケーションの構築を支援する。コンポジションルートと依存性注入は、具体的な実装への直接的な結合を防ぎ、InversifyJSコンテナが抽象的なポートとアダプターをアプリケーション起動時に紐づける。タグベースのキャッシングは、状態の不整合や不必要なデータ取得を防ぎ、クエリがタグを登録し、コマンドがイベントハンドラーを通じてタグの無効化をトリガーする。インメモリフェイクは、遅くて不安定なネットワークモックを排除し、テストコンテナ内で実際のAPIアダプターをインメモリのリポジトリに置き換える。そして、純粋なドメインテストは、DOMセットアップのオーバーヘッドやテストの不安定さをなくし、JSDOMやフレームワークの依存関係なしに、純粋なTypeScriptクラスに対してテストを実行することを可能にする。これらのパターンを組み合わせることで、スケーラブルで高品質なソフトウェア開発が可能となるのだ。