Feature-Sliced Desingを学ぶ
前書き
アーキテクチャを学んでいる中で下記の記事を見つけてFeature-Sliced Designに出会いました
まだ発展途上で情報が少ないものですが、実際にFeature-Sliced Designでコードを書いてみるとコードが書きやすく気持ちよい開発が出来ました
そんなFeature-Sliced Designを自分なりに書いていきます
Feature-Sliced Design
フロントエンドで使用されることを想定されているアーキテクチャの一つ
構成ルール
様々なアーキテクチャと同じようにFeature-Sliced Designにもディレクトリの構成にルールが定まっています
Layers層、Slices層、Segments層の3つ別れていて、Layers層 ＞ Slices層 ＞ Segments層の形で階層になっています
app layerとshared layerは Slices層 を持たず直接 Segments層 を持つルールになっています
Layers層
src
├── app/ # App.tsxやルーティング設定、アプリケーション設定(状態管理、i18n設定など)
├── pages/ # ページ単位で必要な機能・ウィジェットを統合
├── widgets/ # ヘッダーやフッター、サイドバーなどの大きなブロック
├── features/ # アプリケーション特有の機能やユースケース
├── entities/ # アプリケーションで扱うドメインエンティティ(データ構造)関連
└── shared/ # アプリケーション全体で再利用するコンポーネントやユーティリティなど
6つのレイヤーを標準として提供しているが全て使用する必要はないです
使用するかどうかは開発するアプリケーションに合わせていく形になっています
Slices層
Layers層の一段下にある層になります
slices名は決まっていないためビジネスドメインに合わせて分解・命名を行っていきます
禁止されているルールとして同一Layer層内にある別々のSlices層間でimportしてはいけないことになっています
また先述した 「app layerとshared layerは Slices層 を持たず直接 Segments層 を持つルールになっています」となっている理由として
- shared layer層はアプリケーション全体で再利用するものにしか含まないため
- app layer層はアプリケーション全体の設定しか含まれていないため
があり分割する必要がないのでSlices層は存在しません
Segments層
特定の役割・機能に基づいてグループ化していきます
segments名は標準で決まっていないが、公式が慣例的なsegments名を提供してきます
- uiセグメント
- 名前通りUIコンポーネントなど見た目・インターフェイスを管理
- modelセグメント
- ビジネスロジック・状態管理・ドメインモデルの型定義などを管理
- libセグメント
- 汎用的な関数などを管理
- apiセグメント
- 名前通り外部APIとの通信処理を管理
Public API
人によっては「嫌だ」と思うようなコンセプトになります
Slices層に index.ts を配置して index.ts に公開モジュールを記載していきます
書き方としてはSegments層にて短い命名にしてSlices層の index.ts でユニークな名前に命名してからreexportする形が推奨されています
└── features/ # Layer層
├── auth-form / # Slice層
│ ├── ui/ # Segment層
│ ├── model/ # 同上
│ └── {...}/ # 同上
└── index.ts # 公開APIによるエントリーポイント機能(Public API)
export { Form as AuthForm } from "./ui"
export * as authFormModel from "./model"
まとめ
特殊なアーキテクチャですが、今まで出会ったアーキテクチャの中でも自分的には一番相性が良いものでした
今後も新しいアーキテクチャが出てくると思います、出てきたらまた新しく学んでいきたいです
Discussion