株式会社NeverのFlutter設計では3層構成 Presentation → Domain → Infrastructure を基本とした軽量DDDな設計を採用する。

• メリット
  • 保守性（拡張性）の向上とコード管理がしやすい、エンジニア間での実装統一がしやすい
  • 別PJへコード流用がしやすい
  • DDDな設計なので他PJのエンジニアと同じ世界線で意見交換ができる
    • DDD = その業務領域にフォーカスしたソフトウェア設計
• デメリット
  • 実装・学習コストがかかる（慣れるまでの辛抱）

デメリットよりメリットの方が大きいのですぐリカバリーできる

※設計にはこれが正解というものはありません。設計がビジネス要件とマッチしているかが重要だと考えています。本設計をベースとして大きく乖離しない程度にルールや指針を柔軟に決めれば良いと考えています。

設計

※ Modelの概念はMVCから引用しています

モデルはそのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。また、データの変更をビューに通知するのもモデルの責任である（モデルの変更を通知するのにObserver パターンが用いられることもある）。 引用元: https://ja.wikipedia.org/wiki/Model_View_Controller

• Presentation
  • UIの実装
    • Page、Widget、Dialog等
  • UIの状態を保持（入力フォームに入力したテキストデータ等）
• UseCase
  • ビジネスロジックを実装し、そのロジックで確定した状態を保持する
  • 単一責任の原則に従う
    • ビジネスロジックによって確定される状態は1つであるべき
    • 1ビジネスロジック = 1ファイルで管理する
      • fetch_user_profile.dart
        • Userの状態を取得する実装
      • post_controller.dart
        • Postの状態を操作（CRUD）する実装
  • メリット
    • やりたい実装の粒度が明確になり、保守がしやすい、コンフリクトが起きにくい
  • デメリット
    • ファイル数が増える
• Repository
  • データソースを隠蔽化（カプセル化）して使いやすいIFを提供するもの
  • メリット
    • 隠蔽することで、隠蔽したものに仕様変更が生じても、その影響範囲をRepository内で抑えることができる
  • デメリット
    • Repositoryのコード量が増える
• Entity
  • UseCaseの状態やRepositoryから取得したデータをデータクラスとして管理する
  • メリット
    • データを安全に扱える
    • そのデータの関心事を集約できる
      • データクラスが持つプロパティを表示用として別プロパティとして扱いたい場合、データクラスのgetterとして定義して管理できる
  • デメリット
    • ない

ディレクトリ構成

LayerFirst

設計の3階層を意識したディレクトリ構成です。

https://github.com/hukusuke1007/flutter_app_template/tree/main/layer_first

**- model
    - entities
    - use_cases**
        - fetch_latest_app_version.dart
        - sign_in_with_email.dart
        - sign_up_with_email.dart
        - user_me_controller.dart
				- ...
    **- repositories**
**- presentation
    - pages**
        - onboarding_page.dart
        - sign_up_page.dart
        - sign_out_page.dart
				- ...
    **- widgets**

• メリット
  • 画面毎に実装できるため、迷うことなく実装できる