Feature-Sliced Design：本質と機能ベース分割の方法論

Feature-Sliced Designとは？

Feature-Sliced Design (FSD)は、2021年にfeature-sliced.designコミュニティによって初めて提案されたフロントエンドアプリケーションアーキテクチャ方法論です。FSDの核となるアイデアは、コードをビジネス機能（スライス）ごとにグループ化することで、各スライスは自己完結型のユニットであり、独自のビジネスロジック、ユーザーインターフェース、API連携、データモデル、テストを含みます。これによりFSDは、コードが技術的基準（controller、service、repository）で分割される従来の層状アーキテクチャとは異なります。

この方法論は、Domain-Driven Design（DDD）とBounded Contextの概念を借用しています。アプリケーションの各機能は、明確な境界を持つ独立したbounded contextです。スライスのパブリックAPIのみを使用している限り、ある機能内の変更は他の機能を壊してはいけません。State of Frontend 2024の調査によると、FSDはReactアーキテクチャの中で人気第2位（23%）であり、非公式のFeature-based構造（31%）に次いでいます。

モバイル開発では、FSDはAndroidモジュールとiOSフレームワークの特性に適応します。IT Sectrでは、10画面以上、3チーム以上のプロジェクトにFSDを使用しています。この方法論により、機能を独立して開発でき、スライス境界のないモノレポと比較してgitの競合が40%減少します。

FSDの7層：構造とインポートルール

FSDは7つの階層層を定義し、各層には特定の抽象化レベルのコードが含まれます。主要なアーキテクチャルールは、層は下位層からのみコードをインポートできることです。このルールに違反する（entitiesにfeatures層をインポートする）ことはアーキテクチャエラーと見なされ、リンターによってブロックされます。

FSDプロジェクトのディレクトリ構造例：

src/
├── app/                    // アプリケーション層
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // ページ — 機能構成
│   └── main/
├── features/                // 機能 — ユーザーシナリオ
│   ├── auth/                // スライス「認証」
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // スライス「商品一覧」
│       ├── ui/
│       └── model/
├── entities/                // ビジネスエンティティ
│   ├── user/
│   └── product/
├── widgets/                 // 複合コンポーネント
│   └── header/
└── shared/                  // 共有ユーティリティとUI-kit
    └── ui/

「層は下方向のみを見る」ルールはFSDの基盤です。feature authがentity userをインポートするのは正しいです。entity userがfeature authをインポートし始めると、それは循環依存と分離違反です。このルールを強制するために、ESLintプラグイン（eslint-plugin-fsd）やスライスのパブリックAPIのカスタムリンターが使用されます。

スライス：ビジネスドメインの境界

スライス（Slice） — FSDにおけるグループ化の主要単位で、1つのビジネス機能またはエンティティに対応します。各スライスは7層（features、entities、widgets、pages）のいずれかに存在し、特定の機能を実装するための完全なコードセット（UIコンポーネント、データモデル、APIクライアント、定数、テスト）を含みます。

スライス境界はビジネスドメインによって定義されます。feature authは認証に関するすべて（ログインフォーム、登録フォーム、パスワードリセット）を含みます。entity userはUserモデル、UserRepository、シリアライゼーションを含みます。境界は重複すべきではありません。feature authがユーザーデータを必要とする場合、ロジックを複製する代わりにentity userをインポートします。モバイル開発では、FSDスライスはAndroidのGradleモジュールやiOSのSwiftパッケージに対応することがよくあります。

スライスは厳密に分離されています。あるスライスの内部構造は他のスライスから見えません。スライス間の相互作用には、パブリックAPI（外部使用が許可されたもののみをエクスポートするindex.ts/index.jsファイル）が使用されます。それ以外はすべてプライベートモジュールです。このアプローチは偶発的な依存関係を防ぎ、リファクタリングを容易にします。あるスライスのプライベート実装を変更しても他のスライスに影響しません。

セグメント：スライス内のUI、API、Model、Lib

各FSDスライス内では、コードはさらにセグメントによって整理されます。これはすべてのスライスで繰り返される技術的カテゴリです。標準セグメントセットには、ui（インターフェースコンポーネント）、model（ビジネスロジック、Store、Actions、Reducer）、api（サーバーリクエスト、ミューテーション）、lib（ユーティリティとヘルパー）、config（機能設定）が含まれます。

セグメントは推奨事項であり、厳格なルールではありません。スライスが小さい場合、セグメントは統合できます。大きなスライス（10ファイル以上の機能）の場合、セグメンテーションは必須です。それがないと、内部構造はすぐに50ファイルの「かご」と化し、必要なコンポーネントを見つけるのに数分かかります。モバイル開発では、セグメントはタイプ別のファイル構造に置き換えられることがよくあります。各機能は内部型を持つ独立したSwiftファイルまたはKotlinクラスです。

モバイル開発におけるFSD：AndroidとiOSへの適応

モバイル開発では、FSDはプラットフォーム固有の特性（Androidのモジュール構造（Gradleモジュール）とSwift Package Manager）に適応します。Android適応では、各スライスが独自のbuild.gradleを持つ独立したGradleモジュールであると想定します。モジュールfeature-auth、feature-profile、entity-user、shared-uiはビルドレベルで相互に分離されています。feature-authは、dependenciesで指定されていない限り、feature-profileをインポートできません。

iOS適応はSwift Package Managerに基づいています。各スライスはパブリックAPIを持つSwiftパッケージです。TCAプロジェクトでは、feature.authスライスに独自のReducer、Store、View、APIクライアントが含まれます。Swift Community Survey 2024によると、TCAを使用するiOSプロジェクトの28%がFSDに近いスライスアーキテクチャを使用しています。

モバイルFSD適応の主な問題は、shared層の重複です。モバイル開発では、UIコンポーネント（shared/ui）はプラットフォーム（Android Views vs Jetpack Compose vs SwiftUI）に依存することが多く、各テクノロジーに個別のsharedモジュールが必要です。FSDでは、shared層は通常プラットフォームに依存しません（ユーティリティ、設定）が、UI-kitは別のモジュールまたはコンポーネントライブラリに移動されます。

Feature-Sliced Designの長所と短所

利点 FSDは10名以上の開発者がいる大規模プロジェクトで顕著になります。各開発者またはチームは、他のコードに触れることなく自分のスライスで作業します。gitの競合は40〜60%減少します（feature-sliced.designのケーススタディからのデータ）。新しい機能は、スライスのパブリックAPIのみを使用する限り、既存の機能を壊すリスクなく追加できます。1つの機能のリファクタリングは他に変更を必要としません。パブリックAPIを維持しながら、1つのスライス内のui/model/apiを書き換えるだけで済みます。

欠点 FSDの — 小規模プロジェクトには過剰なネスト。アプリケーションが3〜5画面で構成されている場合、7層と各スライス内のセグメンテーションは、アプリケーション自体よりも多くの組織コードを生成します。参入障壁は高く、新しい開発者は方法論の習得に2〜4週間かかります。また、FSDは迅速なプロトタイピングとの互換性が低いです。プロトタイピングでは頻繁なクロス層インポートが必要ですが、FSDでは禁止されており、反復が遅くなります。

より単純なFeature-based構造から始め、画面数が20を超え、チームが5名を超えたらFSDに移行することをお勧めします。