TL;DR
フロントエンドアプリケーションのコードを整理するための、アーキテクチャの方法論。コードをレイヤ、スライス、セグメントの 3 段階に分け、ビジネスの要件が変わってもプロジェクトを理解しやすく保つことを目指す。
なぜ必要か
プロジェクトが大きくなり、新しいメンバーが加わると、コードベースは管理しにくくなる。FSD は、コードの置き場所とレイヤの間の依存の向きを決まりとして定め、ビジネスのドメインを軸にコードを整理する。
仕組み
コードは次の 3 段階で分ける。
- レイヤ: 最上位のフォルダ。名前は全プロジェクトで共通だが、すべてを使う必要はない
- スライス: レイヤの中を、ビジネスのドメインで分けたもの。名前は自分で決める
- セグメント: スライスの中を、技術的な目的で分けたもの。
ui、api、model、lib、configなどがよく使われる
標準のレイヤは、上から App、Processes（非推奨）、Pages、Widgets、Features、Entities、Shared の順に並ぶ。App と Shared はスライスを持たず、直接セグメントに分ける。
モジュールは、自分より下のレイヤからしか import できない。同じレイヤのスライスどうしも、互いに import できない。
注意点
ライブラリではなく、アプリケーションのための方法論である。言語や UI フレームワーク、状態管理のライブラリを問わず、段階的に導入でき、モノレポでも使える。ただし、今のアーキテクチャがうまく機能しているなら、移行するコストに見合わないことがある。