v1からの移行
なぜv2なのか？
初期のfeature-slicesの概念は、2018年に提唱されました。
それ以来、FSD方法論は多くの変革を経てきましたが、基本的な原則は保持されています。
- 標準化されたフロントエンドプロジェクト構造の使用
- アプリケーションをビジネスロジックに基づいて分割
- 孤立した機能の使用により、暗黙の副作用や循環依存を防止
- モジュールの「内部」にアクセスすることを禁止する公開APIの使用
しかし、以前のバージョンのFSD方法論には依然として弱点が残っていました。
- ボイラープレートの発生
- コードベースの過剰な複雑化と抽象化間の明確でないルール
- プロジェクトのメンテナンスや新しいメンバーのオンボーディングを妨げていた暗黙のアーキテクチャ的決定
新しいバージョンのFSD方法論（v2）は、これらの欠点を解消しつつ、 既存の利点を保持することを目的としています。
2018年以降、feature-drivenという別の類似の方法論が発展してきました。それを最初に提唱したのはOleg Isonenでした。
2つのアプローチの統合により、既存のプラクティスが改善され、柔軟性、明確さ、効率が向上しました。
結果として、方法論の名称も「feature-sliced」に変更されました。
なぜプロジェクトをv2に移行する意味があるのか？
WIP:現在の方法論のバージョンは開発中であり、一部の詳細は変更される可能性があります。
🔍 より透明でシンプルなアーキテクチャ
FSD（v2）は、より直感的で、開発者の間で広く受け入れられている抽象化とロジックの分割方法を提供しています。
これにより、新しいメンバーの参加やプロジェクトの現状理解、アプリケーションのビジネスロジック分配に非常に良い影響を与えます。
📦 より柔軟で誠実なモジュール性
FSD（v2）は、より柔軟な方法でロジックを分配することを可能にしています。
- 孤立した部分をゼロからリファクタリングできる
- 同じ抽象化に依存しつつ、余計な依存関係の絡みを避けられる
- 新しいモジュールの配置をよりシンプルにできる (layer → slice → segment)
🚀 より多くの仕様、計画、コミュニティ
core-teamは最新の（v2）バージョンのFSD方法論に積極的に取り組んでいます。
したがって、以下のことが期待できます。
- より多くの記述されたケース/問題
- より多くの適用ガイド
- より多くの実例
- 新しいメンバーのオンボーディングや方法論概念の学習のための全体的な文書の増加
- 方法論の概念とアーキテクチャに関するコンベンションを遵守するためのツールキットのさらなる発展
もちろん、初版に対するユーザーサポートも行われますが、私たちにとっては最新のバージョンが最優先です。
将来的には、次のメジャーアップデートの際に、現在のバージョン（v2）へのアクセスが保持され、チームやプロジェクトにリスクをもたらすことはありません。
Changelog
BREAKING Layers
FSD方法論は上位レベルでの層の明示的な分離を前提としています。
/app>/processes>/pages>/features>/entities>/shared- つまり、すべてがフィーチャーやページとして解釈されるわけではない
- このアプローチにより、層のルールを明示的に設定することが可能になる
-
モジュールの層が高いほど、より多くのコンテキストを持つことができる
(言い換えれば、各層のモジュールは、下層のモジュールのみをインポートでき、上層のモジュールはインポートできない)
-
モジュールの層が低いほど、変更を加える際の危険性と責任が増す
(一般的に、再利用されるのは下層のモジュールらからである)
-
BREAKING Shared層
以前はプロジェクトのsrcルートにあった インフラストラクチャの /ui, /lib, /api 抽象化は、現在 /src/shared という別のディレクトリに分離されています。
shared/ui- アプリケーションの共通UIキット（オプション）- ここで
Atomic Designを使用することは引き続き許可されている
- ここで
shared/lib- ロジックを実装するための補助ライブラリセット- 引き続き、ヘルパー関数の「ごみ屋敷」を作らずに
shared/api- APIへのアクセスのための共通エントリポイント- 各フィーチャー/ページにローカルに記述することも可能だが、推奨されない
- 以前と同様に、
sharedにはビジネスロジックへの明示的な依存関係があってはならない- 必要に応じて、この依存関係は
entities、またはそれ以上の層に移動する必要がある
- 必要に応じて、この依存関係は
新規 Entities層, Processes層
v2では、ロジックの複雑さと強い結合の問題を解消するために、新しい抽象化が追加されました。
/entities- ビジネスエンティティの層で、ビジネスモデルやフロントエンド専用の合成エンティティに関連するスライスを含む- 例：
user,i18n,order,blog
- 例：
/processes- アプリケーション全体に わたるビジネスプロセスの層- この層はオプションであり、通常はロジックが拡大し、複数のページにまたがる場合に使用が推奨される
- 例：
payment,auth,quick-tour
BREAKING 抽象化と命名
具体的な抽象化とその命名に関する明確なガイドラインが定義されています。
Layers
/app— アプリケーションの初期化層- 以前のバリエーション:
app,core,init,src/index
- 以前のバリエーション:
/processes— ビジネスプロセスの層- 以前のバリエーション:
processes,flows,workflows
- 以前のバリエーション:
/pages— アプリケーションのページ層- 以前のバリエーション:
pages,screens,views,layouts,components,containers
- 以前のバリエーション:
/features— 機能部分の層- 以前のバリエーション:
features,components,containers
- 以前のバリエーション:
/entities— ビジネスエンティティの層- 以前のバリエーション:
entities,models,shared
- 以前のバリエーション:
/shared— 再利用可能なインフラストラクチャコードの層 🔥- 以前のバリエーション:
shared,common,lib
- 以前のバリエーション:
Segments
/ui— UIセグメント 🔥- 以前のバリエーション：
ui,components,view
- 以前のバリエーション：
/model— ビジネスロジックのセグメント 🔥- 以前のバリエーション：
model,store,state,services,controller
- 以前のバリエーション：
/lib— 補助コードのセグメント- 以前のバリエーション：
lib,libs,utils,helpers
- 以前のバリエーション：
/api— APIセグメント- 以前のバリエーション：
api,service,requests,queries
- 以前のバリエーション：
/config— アプリケーション設定のセグメント- 以前のバリエーション：
config,env,get-env
- 以前のバリエーション：
REFINED 低結合
新しいレイヤーのおかげで、モジュール間の低結合の原則を遵守することがはるかに簡単になりました。
それでも、モジュールを「切り離す」ことが非常に難しい場合は、できるだけ避けることが推奨されます。