22 y.o. front-end developer with a special love for learning and creating
This story contains new, firsthand information uncovered by the writer.
The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)
This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.
フロントエンド開発者は、アプリケーション アーキテクチャに関連する問題に直面することがよくあります。これには、簡単に拡張でき、アプリケーション モジュール間に疎結合と高い凝集性を提供できるアーキテクチャを使用する必要があります。
この記事では、機能スライス設計アーキテクチャについて説明します。私の意見では、これが利用可能なオプションの中で最良であると考えています。また、FSD の考え方と、このアーキテクチャ方法論が解決する問題についても説明します。
FSD を従来のアーキテクチャおよびモジュラー アーキテクチャと比較し、その長所と短所を検討します。
何よりもまず、レイヤー、スライス、セグメントという 3 つの概念を区別しましょう。
レイヤー、スライス、セグメント
レイヤーはトップレベルのディレクトリであり、アプリケーション分解の最初のレベルです。それらの数は最大 7 層に制限されており、標準化されていますが、一部はオプションです。
現在、次のレイヤーが区別されています。
レイヤー
これらのレイヤーは、コードベースを整理し、モジュール式で保守可能でスケーラブルなアーキテクチャを促進するのに役立ちます。
Github レイヤー
機能スライス設計の重要な機能の 1 つは、その階層構造です。この構造では、フィーチャが階層の上位にあるため、エンティティはフィーチャの機能を使用できません。
同様に、上のレイヤーは下のレイヤーのみを利用できるため、機能ではウィジェットやプロセスのコンポーネントを使用できません。これは、一方向のみに向けられた直線的な流れを維持するために行われます。 層構造
各層には、アプリケーション分解の第 2 レベルであるサブディレクトリ (スライス) があります。スライスでは、接続は抽象的なものではなく、特定のビジネス エンティティに行われます。スライスの主な目的は、コードを値ごとにグループ化することです。
スライス名はプロジェクトのビジネス領域によって直接決定されるため、標準化されていません。たとえば、フォト ギャラリーには、写真、アルバム、ギャラリーなどのセクションがある場合があります。ソーシャル ネットワークには、投稿、ユーザー、ニュースフィードなどのスライスが必要です。
密接に関連したフラグメントは構造的にディレクトリにグループ化できますが、他のスライスと同じ分離ルールに従う必要があります。このディレクトリ内のコードへの共有アクセスがあってはなりません。
スライス
各スライスはセグメントで構成されます。セグメントは、目的に基づいてスライス内のコードを分割するのに役立ちます。チームの合意に応じて、セグメントの構成と名前が変更される場合があります。以下のセグメントがより一般的に使用されます。
各スライスとセグメントにはパブリック API があります。パブリックAPIはindex.jsまたはindex.tsファイルで表現され、スライスやセグメントから必要な機能だけを外部に抽出し、不要な機能を分離することができます。インデックス ファイルはエントリ ポイントとして機能します。
パブリック API のルール:
パブリック API を使用すると、インポートとエクスポートの操作が簡素化されるため、アプリケーションに変更を加えるときに、コード内のあらゆる場所でインポートを変更する必要がありません。
パブリックAPI
レイヤーが高くなるほど、特定のビジネス ノードとの結びつきが強くなり、含まれるビジネス ロジックも多くなります。レイヤーが下位になるほど、抽象化が進み、再利用性が高まり、レイヤー内の自律性が失われます。
レイヤーの抽象化
機能スライス設計のタスクの 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 の使用例や、フィーチャースライス設計の公式ドキュメントを独自に調べることもできます。
この投稿は長いかもしれませんが、何か新しいことを学んでいただければ幸いです。最後までお読みいただきありがとうございます。
ご意見やご質問がございましたら、お気軽にコメントを残してください。
ここでも公開されています