Flutterにおけるアーキテクチャ考察
yamazaking要約
いろいろ記事を読んでみた感じ現時点（2024年1月時点）では、決定版はない感じ。
というか、そもそも設計に決定版などなく、チームメンバーの理解度やプロジェクト、コードの内容によって適切な設計が変わってくる、というほうが正しい気がする。
企業ブログとかで見た感じだど、Clean Architecture+MVVMみたいなのが多い。まだFlutterがモバイルアプリで使われるようになって日が浅いということもあり、Reactを参考にした設計パータンを採用しているところもあった。Reactに慣れ親しんだ人が多いチームでは、そういう決定もありかも。
一番わかりやすく、汎用的なのはmonoさんの記事
ここに書いてる原則を守れば、それなりに問題のないプログラムが出来る感じ。以下引用
Single Source of Truth(SSOT)原則に従った状態管理
状態の流れを単方向データフローで組む
次点で以下(上の2点ほど遵守必須ではないが大抵守る方が良い)だと思っています。
immutableプログラミングの徹底
Unit/Widget Testが可能に
単一責任の原則を意識
読んでいて、結構驚きだったのは、プロジェクトの階層をレイヤー単位ではなく、機能単位で分割していた。
こうすることで、機能の中でView、modelなどを認識しやすくなるという。
monoさんのGitHubリポジトリに、サンプルコードとかもあがっているので適宜参照したい。
yamazaking企業プロダクトで採用している設計について
WINTICKET
CA,Riverpod, Flutter Hooks. Web界隈（主にReact）からの知見も参考に取り入れている。
DeNA
CA→疎結合、責務の分離、テスタビリティなどのメリット
ローソンデジタルイノベーション
CA+MVVM
選定理由
CA→従来開発していたiOS,AndroidでCAを使っており、CAのメリットを享受できる
MVVM→MVVMのメリットを享受できる
Prntagon
MVVM
コードの理解しやすさ、状態管理のわかりやすさ
KINTO
MVVM+Repository
バックエンドにCAを使っている。
UUUO
MVC+Repository→CQRS+Repository
当初MVCでやっていたが、Cが肥大化
新アーキテクチャでは、
- 状態操作系のロジックを小さく切り出して閉じ込める (Widget になるべく近くする)
- コントローラはデータの取得やアクションを担当する
という設計を目指した。
enechain
MVVM→Reactに習った設計（名称の記述なし）
元々Androidエンジニアがチームに多く、開発速度を高めるためにMVVMを採用
しかし、宣言的ではないところがあったりして、課題を感じていた。FlutterがReactのAPIに似ていることもあり、Reactの事例を参考にした。
CAM
CA
LayerX
※UIコンポーネントの設計
Atomic Design→3要素（Parts. Compaunds, Pages）構成
ADを採用したのは、もともとWebアプリで採用していたから。辞めた理由としては、要素数が多く煩雑さが増え、メンバー間による認識の違いや無駄な記述が増え、開発速度の低下を招いた
StudyPlus
MVP
●番外編
さまざまな設計パターンを比較した記事
詳細を読んでないけど、Androidが公式に推奨している設計がある。Androidの特徴（FragmentやActivity）に則っているが、Flutterでも参考にできるかも