Flutter は 2018 年の登場以降、シンプルな Provider ベースの構成から進化し、2025 年現在では モジュール化・分層化・テスト容易性・セキュリティ を重視したアーキテクチャが主流になっています。
本記事では、特に中〜大規模プロジェクトで採用されている構成例を Mermaid 図付きで解説します。
1. アーキテクチャの変遷
| 時期 | 主な構成 | 状態管理 | データ層 | 依存注入 |
|---|---|---|---|---|
| 2019〜2021 |
lib/直下に画面別フォルダ |
Provider / ScopedModel | API 直叩き | なし / 手動 |
| 2023〜2025 | Feature Module + Core/Shared | Riverpod 2.x / Bloc | Repository + UseCase | get_it / Riverpod DI |
2. 主流アーキテクチャ構成（2025）
-
分層構造: Presentation / Domain / Data の 3 層
-
Feature Modules: 機能単位で Presentation / Domain / Data を完結
-
Core & Shared: ネットワーク・テーマ・共通ウィジェット・ユーティリティ
-
依存注入（DI）: Riverpod の Provider または get_it + injectable
-
データストア: Drift / Isar（+ sqlcipher で暗号化）
-
ルーティング: go_router（公式推奨、宣言的ナビゲーション）
-
テスト戦略: Unit + Widget + Integration/E2E
3. 高レベル構造図（Mermaid）
4. Feature Module 構成例
5. 推奨技術スタック（2025 年版）
- 状態管理: Riverpod 2.x（Notifier/AsyncNotifier）
- ルーティング: go_router
- データベース: Drift / Isar（+ sqlcipher）
- 依存注入: Riverpod Provider または get_it
- モノレポ管理: melos
- 多言語対応: intl / easy_localization
- テスト: flutter_test, mocktail/mocking framework
まとめ
2025 年の Flutter 大規模開発では、
- 機能単位のモジュール化
- Clean Architecture に基づく分層化
- Riverpod を活用した依存注入と状態管理
- セキュリティやテスト戦略の組み込み
が当たり前になっています。
特に features/ + core/ + shared/ 構成は、規模拡大にも耐えられ、チーム開発にも適しています。
今後は Flutter 公式の Impeller レンダラー や 新しい並列処理 API の普及に合わせ、パフォーマンスチューニングを組み込んだアーキテクチャも主流になると考えられます。
Source Code