はじめに
この記事はYUMEMI Flutter Advent Calendar 2023の18日目の記事です。
本題
TL;DR
project_name
├ assets
├ lib
│ ├ apis
│ ├ components
│ ├ configs
│ ├ features
│ │ └ feature
│ │ ├ apis
│ │ ├ components
│ │ ├ hooks
│ │ ├ models
│ │ └ providers
│ ├ gen
│ ├ hooks
│ ├ l10n(or i18n)
│ ├ models
│ ├ pages
│ └ providers
└ test
フロントエンドのディレクトリ構成
自分が1年ほど前までWebのフロントエンドエンジニアとして仕事をしていたため、Reactのディレクトリ構成をよく考えていました。有名なものとしては、Atomic DesignやBCD(BCCD) Design、featuresディレクトリなどです。その中でも、featuresディレクトリを用いるbulletproof-reactを元に、Flutterのディレクトリ構成を考えていきます。
features
featuresディレクトリとは、機能ベースのディレクトリとなっており、featuresディレクトリ以下には各機能の名称のディレクトリを持ちます。例えば、認証機能を提供するauthや、ユーザー情報を提供するuserなどです。
メリットとして、機能ごとに役割が分かれているため、テストの書きやすさにも繋がります。また、不要になった機能はディレクトリを消すだけでよくなり、依存関係を確認したりする手間も省けます。
以下は自分の考えるfeaturesディレクトリの構成になります。
features
└ feature
├ apis
├ components
├ hooks
├ models
└ providers
apis
apisディレクトリではAPI通信の処理を管理します。例えば、httpを使用してユーザー情報の取得などを行い値を返すような関数を定義します。
components
componentsディレクトリではその機能を満たすためのUIを管理します。例えば、ユーザープロフィールを表示する場合だと、user_profile.dartのようなファイルを定義します。
hooks
hooksディレクトリではカスタムフックを管理します。例えば、flutter_hooksのuseState使用して、API通信中かどうかの判定を行います。
models
modelsディレクトリではAPIのレスポンスなどのモデル（型）を管理します。例えば、Freezedを使用して、ユーザー情報のモデルを定義します。
providers
providersディレクトリではプロバイダを管理します。例えば、Riverpodを使用して、複数の画面で使用されるようなユーザーアイコンの画像を持つプロバイダを定義します。
pages
pagesディレクトリはその名の通り、ページごとの名称のディレクトリを持ちます。例えば、ユーザープロフィールを表示するprofileなどです。featuresディレクトリで作成したコンポーネントを用いてUIを構築していきます。
また、このディレクトリで各ページのルーティングも定義します。例えば、go_routerを使用した場合、pathなどをこのディレクトリで定義し、すべてのルーティングを束ねるファイルはlib直下にrouter.dartを作成して対応します。
その他
その他のディレクトリは共通で使用するファイルや環境変数、多言語化対応などを定義します。
以下は自分の考えるディレクトリの構成（featuresディレクトリとpagesディレクトリは省略）になります。
lib
├ apis ... 共通で使用するAPI通信を行うファイル群を管理
├ components ... 共通で使用するコンポーネント群を管理
├ configs ... 環境変数を管理
├ gen ... FlutterGenの出力先として画像などを管理
├ hooks ... 共通で使用するカスタムフック群を管理
├ l10n(or i18n) ... 多言語化対応のためのファイル郡を管理
├ models ... 共通で使用するモデル郡を管理
└ providers ... 共通で使用するプロバイダ群を管理
まとめ
プロジェクトの直下には画像等を管理するassetsディレクトリと、テストを管理するtestディレクトリを追加し、最終的に考えたディレクトリ構成は以下のようになります（iosディレクトリやandroidディレクトリなどは省略しております）。
project_name
├ assets
├ lib
│ ├ apis
│ ├ components
│ ├ configs
│ ├ features
│ │ └ feature
│ │ ├ apis
│ │ ├ components
│ │ ├ hooks
│ │ ├ models
│ │ └ providers
│ ├ gen
│ ├ hooks
│ ├ l10n(or i18n)
│ ├ models
│ ├ pages
│ └ providers
└ test
おわりに
ディレクトリ構成はプロジェクトの規模やプロジェクトのメンバーにも左右されます。自分の紹介したディレクトリ構成もプロジェクトによっては相応しくないかもしれません。
色々なディレクトリ構成を比較する上で、ひとつの案になれれば幸いです。