導入
フロントエンド開発者は、アプリケーション アーキテクチャに関連する問題に直面することがよくあります。これには、簡単に拡張でき、アプリケーション モジュール間に疎結合と高い凝集性を提供できるアーキテクチャを使用する必要があります。
この記事では、機能スライス設計アーキテクチャについて説明します。私の意見では、これが利用可能なオプションの中で最良であると考えています。また、FSD の考え方と、このアーキテクチャ方法論が解決する問題についても説明します。
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 はフロントエンド開発の分野で主要なアーキテクチャ ソリューションとなる可能性があります。
アーキテクチャの長所と短所
利点
- アーキテクチャコンポーネントは簡単に交換、追加、削除できます
- アーキテクチャの標準化
- スケーラビリティ
- この方法論は開発スタックから独立しています。
- 予期しない副作用のないモジュール間の制御された明示的な接続。
- ビジネス指向のアーキテクチャ手法。
短所
- 他の多くのアーキテクチャ ソリューションと比較して参入障壁が高い。
- 意識、チーム文化、コンセプトの遵守が必要です。
- 課題や問題には、後からではなく、すぐに対処する必要があります。コードの問題やコンセプトからの逸脱はすぐにわかります。ただし、これは利点とも言えます。
結論
機能スライス設計は、フロントエンド開発者が知っておき、使用できるようにする必要がある興味深い貴重な発見です。 FSD は、柔軟で標準化されたスケーラブルなアーキテクチャと開発文化をチームに提供できます。ただし、この方法論のポジティブな側面を活用するには、チーム内の知識、意識、規律が必要です。
FSD は、その明確なビジネス指向、エンティティ定義、機能構成、およびアプリケーションのコンポーネント構成により、他のアーキテクチャの中でも際立っています。
プロジェクトでの FSD の使用例や、フィーチャースライス設計の公式ドキュメントを独自に調べることもできます。
この投稿は長いかもしれませんが、何か新しいことを学んでいただければ幸いです。最後までお読みいただきありがとうございます。
ご意見やご質問がございましたら、お気軽にコメントを残してください。
ここでも公開されています
