導入
私は現在メインの業務ではモバイルアプリ開発はしていませんが、過去にモバイルアプリ開発に携わったことがあります。
当時はFlutter1から2にバージョンアップしたばかりの頃で、小規模開発でしたので、そこまでディレクトリ構成を意識して作成することはありませんでした。
Flutter3になった頃にはモバイルアプリ開発から離れていたので、個人開発でFlutter3に触れ、いくつかモバイルアプリを開発してきました。
業務で利用する際は意識しなかったディレクトリやテストについてもしっかりと考えるようになりました。
今回は、私が個人開発でFlutterを利用する中で、現在でも利用するディレクトリ構成が出来上がったので紹介していきたいと思います。
ディレクトリ構成
基本構造
lib/
├── main.dart
├── core/
│ ├── exceptions/
│ ├── utils/
│ └── constants/
├── data/
│ ├── models/
│ ├── repositories/
│ └── services/
├── domain/
│ ├── entities/
│ ├── use_cases/
│ └── repositories/
├── presentation/
│ ├── view_models/
│ ├── views/
│ │ ├── common/
│ │ └── feature/
│ └── widgets/
│ ├── common/
│ └── feature/
├── routes/
└── di/
解説は後ほど。
テストディレクトリ構成
test/
├── unit/
│ ├── core/
│ ├── data/
│ ├── domain/
│ └── presentation/
│ ├── view_models/
│ └── widgets/
└── widget/
├── common/
└── feature/
integration_test/
├── common/
└── feature/
基本構造の解説
- lib/core/
- exceptions: アプリケーション全体で使う例外クラス
- utils: 汎用的なユーティリティ関数やエクステンション
- constants: 定数やアプリケーション設定
- lib/data/
- models: Freezedを用いて定義したデータモデル
- repositories: データソース（APIやローカルデータベース）へのアクセスを提供
- services: 外部サービスとの通信ロジック
- lib/domain/
- entities: アプリケーションのドメインエンティティ
- use_cases: ビジネスロジックをカプセル化したユースケース
- repositories: ドメイン層で使用するリポジトリのインターフェース
- lib/presentation/
- view_models: Riverpodを使用したViewModel（状態管理）
- views: 各画面のビュー
- common: 複数の画面で共有されるビュー
- feature: 各機能に関連するビュー
- widgets: ウィジェットコンポーネント
- common: 複数の画面で共有されるウィジェット
- feature: 特定の機能に関連するウィジェット
- lib/routes/
... ルーティング設定 - lib/di/
... 依存性注入の設定
最後に
正直ディレクトリ構成に関しては、チームや開発者の好みによるところもあります。
私は、疎結合・テスト容易性を重視する(ようになった)ので、今回のディレクトリ構成にしています。
ご参考になれば幸いです。