2,121 測定値

最高の複雑なフロントエンドアーキテクチャ: 機能スライス設計について知っておくべきこと

に Yan Levin8m2024/01/18

長すぎる; 読むには

この記事では、機能スライス設計アーキテクチャについて説明します。私の意見では、これが利用可能なオプションの中で最良であると考えています。また、FSD の考え方と、このアーキテクチャ方法論が解決する問題についても説明します。

featured image - 最高の複雑なフロントエンドアーキテクチャ: 機能スライス設計について知っておくべきこと

導入

フロントエンド開発者は、アプリケーションアーキテクチャに関連する問題に直面することがよくあります。これには、簡単に拡張でき、アプリケーションモジュール間に疎結合と高い凝集性を提供できるアーキテクチャを使用する必要があります。

FSD を従来のアーキテクチャおよびモジュラーアーキテクチャと比較し、その長所と短所を検討します。

何よりもまず、レイヤー、スライス、セグメントという 3 つの概念を区別しましょう。

レイヤー

レイヤーはトップレベルのディレクトリであり、アプリケーション分解の最初のレベルです。それらの数は最大 7 層に制限されており、標準化されていますが、一部はオプションです。

現在、次のレイヤーが区別されています。

各層には独自の責任領域があり、ビジネス指向です。各層を個別に考えてみましょう。

app: ここでアプリケーションロジックが初期化されます。プロバイダー、ルーター、グローバルスタイル、グローバル型宣言などがここで定義されます。これはアプリケーションのエントリポイントとして機能します。

プロセス: この層は、複数ステップの登録など、複数のページにまたがるプロセスを処理します。このレイヤーは非推奨であると考えられていますが、依然として時々発生する可能性があります。オプションのレイヤーです。

ページ: このレイヤーにはアプリケーションのページが含まれます。

ウィジェット: これらはページで使用されるスタンドアロン UI コンポーネントです。

機能: この層は、ビジネス価値をもたらすユーザーシナリオと機能を扱います。たとえば、「いいね！」、レビューの作成、製品の評価などです。これはオプションのレイヤーです。

エンティティ: このレイヤーはビジネスエンティティを表します。これらのエンティティには、ユーザー、レビュー、コメントなどが含まれます。これはオプションのレイヤーです。

共有: この層には、特定のビジネスロジックに関連付けられていない再利用可能なコンポーネントとユーティリティが含まれています。これには、UI キット、Axios 構成、アプリケーション構成、ビジネスロジックに束縛されないヘルパーなどが含まれます。

これらのレイヤーは、コードベースを整理し、モジュール式で保守可能でスケーラブルなアーキテクチャを促進するのに役立ちます。

機能スライス設計の重要な機能の 1 つは、その階層構造です。この構造では、フィーチャが階層の上位にあるため、エンティティはフィーチャの機能を使用できません。

同様に、上のレイヤーは下のレイヤーのみを利用できるため、機能ではウィジェットやプロセスのコンポーネントを使用できません。これは、一方向のみに向けられた直線的な流れを維持するために行われます。階層内でレイヤーが下位に位置するほど、コード内のより多くの場所で使用される可能性が高いため、レイヤーを変更するリスクが高くなります。たとえば、共有レイヤーの UI キットは、機能、ウィジェット、さらにはページレイヤーでも使用されます。

スライス

各層には、アプリケーション分解の第 2 レベルであるサブディレクトリ (スライス) があります。スライスでは、接続は抽象的なものではなく、特定のビジネスエンティティに行われます。スライスの主な目的は、コードを値ごとにグループ化することです。

スライス名はプロジェクトのビジネス領域によって直接決定されるため、標準化されていません。たとえば、フォトギャラリーには、写真、アルバム、ギャラリーなどのセクションがある場合があります。ソーシャルネットワークには、投稿、ユーザー、ニュースフィードなどのスライスが必要です。

密接に関連したフラグメントは構造的にディレクトリにグループ化できますが、他のスライスと同じ分離ルールに従う必要があります。このディレクトリ内のコードへの共有アクセスがあってはなりません。

セグメント

各スライスはセグメントで構成されます。セグメントは、目的に基づいてスライス内のコードを分割するのに役立ちます。チームの合意に応じて、セグメントの構成と名前が変更される場合があります。以下のセグメントがより一般的に使用されます。

api - 必要なサーバーリクエスト。

UI - スライスの UI コンポーネント。

モデル - ビジネスロジック、つまり状態との対話。たとえば、アクションやセレクターなどです。
lib - スライス内で使用される補助機能。

config - スライスの必要な構成ですが、config セグメントが出現することはほとんどありません。

consts - 必要な定数。

パブリックAPI

各スライスとセグメントにはパブリック API があります。パブリックAPIはindex.jsまたはindex.tsファイルで表現され、スライスやセグメントから必要な機能だけを外部に抽出し、不要な機能を分離することができます。インデックスファイルはエントリポイントとして機能します。

パブリック API のルール:

アプリケーションのスライスとセグメントは、パブリック API インデックスファイルで定義されているスライスの機能とコンポーネントのみを使用します。

パブリック API で定義されていないスライスまたはセグメントの内部部分は、分離されているとみなされ、スライスまたはセグメント自体内でのみアクセスできるようになります。

パブリック API を使用すると、インポートとエクスポートの操作が簡素化されるため、アプリケーションに変更を加えるときに、コード内のあらゆる場所でインポートを変更する必要がありません。

建築をより深く理解する

抽象化とビジネスロジック

レイヤーが高くなるほど、特定のビジネスノードとの結びつきが強くなり、含まれるビジネスロジックも多くなります。レイヤーが下位になるほど、抽象化が進み、再利用性が高まり、レイヤー内の自律性が失われます。

FSD はどのように問題を解決しますか?

機能スライス設計のタスクの 1 つは、疎結合と高い凝集性を実現することです。 FSD がどのようにしてこの結果を達成したかを理解することが重要です。

OOP では、これらの問題は、ポリモーフィズム、カプセル化、継承、抽象化などの概念を通じて長い間解決されてきました。これらの概念により、コードの分離、再利用性、多用途性が保証され、コンポーネントまたは機能の使用方法に応じて異なる結果が得られます。

機能スライス設計は、これらの原則をフロントエンドに適用するのに役立ちます。

抽象化と多態性はレイヤーを通じて実現されます。下位層は抽象的なため、上位層で再利用でき、条件に応じて、コンポーネントまたは機能は、指定されたパラメーターまたはプロパティに基づいて異なる動作をすることができます。

カプセル化はパブリック API を通じて実現され、外部から不要なものをスライスとセグメントに分離します。スライスの内部セグメントへのアクセスは制限されており、パブリック API がスライスまたはセグメントから機能やコンポーネントにアクセスする唯一の方法です。

上位層は下位層を再利用できるため、継承は層を通じても実現されます。

古典的なアーキテクチャとの比較

皆さんも古典建築に何度も出会ったことがあると思います。そのシンプルさのため、ほとんどの著者は教育記事や YouTube ビデオでこれを使用しています。古典的な建築には特別な基準はありません。ただし、多くの場合、次の形式が表示されます。

古典的なアーキテクチャには顕著な欠点があります。最も大きな問題は、コンポーネント間の暗黙的な接続とモジュールの乱雑さにより、プロジェクトの維持が困難になることです。古典的なアーキテクチャの欠点は、時間の経過とともに明らかになります。プロジェクトが長くなるほど、アプリケーションアーキテクチャは複雑に絡み合い、解明するのが難しくなります。

クラシックなアーキテクチャは、継続的なメンテナンスやペットプロジェクトのない小規模なプロジェクトに適しています。

機能スライス設計は、その概念と標準のおかげで、古典的なアーキテクチャの問題を防ぎます。

ただし、FSD を使用する開発者の理解とスキルのレベルは、クラシックアーキテクチャを使用する場合よりも高くなる必要があります。通常、経験が 2 年未満の開発者は FSD について聞いたことがありません。

ただし、機能スライス設計を使用する場合、問題は「後で」ではなく「今」対処する必要があります。コードの問題やコンセプトからの逸脱がすぐに明らかになる

単純なモジュラーアーキテクチャとの比較

単純なモジュラーアーキテクチャにはいくつかの欠点があります。

場合によっては、機能をモジュールまたはコンポーネントのどこに配置するかが不明瞭になることがあります。

別のモジュール内でモジュールを使用する際の困難。

ビジネスエンティティの保存に関する問題。

グローバル関数の暗黙的な依存関係により、複雑な構造が生じます。

複雑または中程度に複雑なプロジェクトでは、単純なモジュラーアーキテクチャよりも機能をスライスした設計を優先する必要があるようです。 FSD は多くの基本的なアーキテクチャ上の問題を解決し、欠点はほとんどありません。

シンプルさと開発速度の点では、シンプルなモジュラーアーキテクチャの方が FSD よりも有利である可能性があります。 MVP が必要な場合、または短期間のプロジェクトが開発されている場合は、FSD よりも単純なモジュール式アーキテクチャの方が適している可能性があります。しかし、それ以外の場合には、機能をスライスしたデザインの方が望ましいように見えます。

機能をスライスした設計の可能性

FSD は若いアーキテクチャ手法です。ただし、すでに多くの銀行、フィンテック、B2B、電子商取引企業などで使用されています。これは、企業のリストを含む GitHub の問題へのリンクです: GitHub Issue 。

公式 FSD ドキュメントを含む GitHub リポジトリには、この記事の公開時点で 1.1,000 個を超えるスターが付いていました。ドキュメントは積極的に拡張されており、FSD 開発チームと Telegram および Discord のコミュニティは年中無休でアーキテクチャ関連の質問に対応しています。

このアーキテクチャの可能性は高く評価されており、世界中の大企業でその利用が広がっています。適切に採用されれば、FSD はフロントエンド開発の分野で主要なアーキテクチャソリューションとなる可能性があります。