flutter-architecture

Flutter アーキテクチャ

責務を明確に保ち、状態をテスト可能にし、依存関係を置き換えられる、最もシンプルなアーキテクチャを選びます。

移行前に現状を維持する

既存の機能構成、状態管理の仕組み、依存性注入、データソース、テスト、チームの規約を確認します。好みの例と異なる場合でも、一貫性のあるアーキテクチャを拡張してください。具体的な問題がある場合にのみ移行を提案し、段階的に進めます。

基本となる境界

• ビューは状態を表示し、ユーザーの意図を転送します。データアクセスとビジネスルールはウィジェットの外部に保ちます。
• プレゼンテーションロジックは UI の状態とコマンドを管理します。
• リポジトリはドメインデータの信頼できる情報源となり、サービスやキャッシュを連携させます。
• サービスは HTTP、ストレージ、プラットフォームプラグインなどの外部システムをラップします。
• ロジックが再利用される場合、複雑な場合、またはプレゼンテーションの状態が煩雑になる場合にのみ、ユースケースやドメインサービスを追加します。
• 置き換えやテストに役立つ場合は、明示的なインターフェースを介して依存関係を内側に向けます。

Flutter チームの MVVM ガイダンスは、新しいスケーラブルなアプリケーションにおける有用なデフォルトであり、Riverpod、Bloc、Redux、または確立された機能優先の設計を置き換える義務ではありません。

構成

ユーザー向けの機能を境界として構成することを優先します。本当に共有されるインフラストラクチャは、小規模なコア領域に配置します。無関係なモデル、ウィジェット、ヘルパーが蓄積するグローバルなフォルダーは避けます。

新規プロジェクトの選択肢や段階的な移行については、グリーンフィールド開発と進化を読み込みます。モジュールが機能をまたいで漏れ出している場合や、所有者が不明確な場合は、機能の境界と依存関係のルールを読み込みます。

検証

1 つの機能について依存関係の経路を示し、実践可能な場合はウィジェットをレンダリングせずにプレゼンテーションロジックをテストし、循環依存や UI からインフラストラクチャへの近道が導入されていないことを確認します。

参考資料

• Flutter アーキテクチャガイド
• 一般的なアーキテクチャの概念