What's the recommended Flutter architecture

by AAkira

Slide 1

Slide 1 text

今新規で作るならFlutterのアーキテクチャってなんなの？ MVVMなの？ Findy Job Lunch Talk Flutter開発の裏側 ~各社が向き合う課題と挑戦~ _a_akira

Slide 2

Slide 2 text

% About me 2 https://aakira.app https://aakira.studio 🐕 ✈ 📷 🎾 🤸 🚁🏠⊿ aakira.studio AAkira _a_akira M3, Inc. Akira Aratani

Slide 3

Slide 3 text

% About me 3 https://aakira.app https://aakira.studio 🐕 ✈ 📷 🎾 🤸 🚁🏠⊿ aakira.studio AAkira _a_akira M3, Inc. Akira Aratani まとめ最近の取り組み WHITE JACKの例デジスマの例 M3の紹介 Findy Job Lunch Talk

Slide 4

Slide 4 text

% M3, Inc. 4 https://www.m3tech.blog/ https://jobs.m3.com/engineer/ エンジニアリングの力で医療の世界を変えていく The Power of Medical Innovation m3_engineering m3_engineering https://jobs.m3.com/product

Slide 5

Slide 5 text

% インターネットを活用し健康で楽しく長生きする人を１人でも増やし、不必要な医療コストを１円でも減らすこと 5

Slide 6

Slide 6 text

% 6 ギークでスマートなエンジニア社内LT回 (隔週開催 286回開催済み) 自由参加にも関わらず、参加者が途絶えたことはない技術ブログ (859記事) 基本的には任意 3日に1回くらいの頻度で更新されている

Slide 7

Slide 7 text

% • 偉い人 < やっちゃいましょう！みんな < やっていき！ • 組織階層がほぼない (役員 → チームリーダー → メンバー) • チームごとに技術選定可能 • バックエンド構成はSlackの #architect で相談 • モバイルはマルチデバイスチーム(アプリ開発横断チーム)と連携して相談 • 全員フルスタックエンジニア 7 エンジニアチームのカルチャー

Slide 8

Slide 8 text

% 8

Slide 9

Slide 9 text

% 9 13Apps

Slide 10

Slide 10 text

% エムスリーのFlutterアプリ 10 Ask Doctors 医師が直接回答す 200万件以上の過 WHITE JACK 福利厚生サービス医師や看護師にセカンドオピニオンができるデジスマ診療予約,問診,支払い等をサポートするサービス患者,クリニック双方に大きなメリットがある

Slide 11

Slide 11 text

% エムスリーのFlutterアプリ 11 Ask Doctors 医師が直接回答するQ&Aサービス 200万件以上の過去の質問も見れるピニオンができる医師キャリア医師のためのキャリア支援サービス

Slide 12

Slide 12 text

% 12 予約・問診通知/チャットチェックイン診察診察後すぐ帰宅薬局に処方箋送付オンライン診察薬を自宅に配送 4.6 App Store review(7.2万件) 8分平均院内滞在時間 28分

Slide 13

Slide 13 text

% 13 予約・問診通知/チャットチェックイン診察診察後すぐ帰宅薬局に処方箋送付オンライン診察薬を自宅に配送 4.6 App Store review(7.2万件) 8分平均院内滞在時間 28分まとめ最近の取り組み WHITE JACKの例デジスマの例 M3の紹介 Findy Job Lunch Talk

Slide 14

Slide 14 text

% • 開発スタートは2020年12月, 初期リリースは4月を目標 • 最初期のエンジニアは3名バックエンド1名, Web1名, アプリ1名途中から1名(バックエンド)追加されてリリース時は4名 • 決済, 認証, QRコード/クレカ読み取りなどのコア機能の技術検証 • アプリ開発者は一旦1人になりそう Android/iOSを出す必要があったため、ネイティブのみでは作らない判断 KMP(Kotlin Multiplatform)も検討 14 デジスマアプリの技術選定

Slide 15

Slide 15 text

% • エムスリーではフルKMPアプリが1つ、一部導入アプリが1つある • ネイティブの機能/UIを使いたい場合はKMPの方が適している • 新規で少人数(1~2名)の場合はFlutterの方が早いかも? • 既存アプリをMultiplatform化したいならKMPの方がオススメ • 最終的には、プロダクトや環境次第 • 私が開発しました😤 https://github.com/AAkira/napier https://github.com/AAkira/Kotlin-Multiplatform-Libraries 15 KMPとの比較

Slide 16

Slide 16 text

% • 2020年当時の流行り BLoC, Redux, GetX, Provider(Riverpod), MVVM • これといったデファクトスタンダードは存在していない時代 • Riverpodを使ったMVVMを採用 16 デジスマアプリの設計

Slide 17

Slide 17 text

% • 2020年当時の流行り BLoC, Redux, GetX, Provider(Riverpod), MVVM • これといったデファクトスタンダードは存在していない時代 • Riverpodを使ったMVVMを採用 17 デジスマアプリの設計まとめ最近の取り組み WHITE JACKの例デジスマの例 M3の紹介 Findy Job Lunch Talk

Slide 18

Slide 18 text

% • 開発スタートは2025年1月, 初期リリースは2月を目標 • 最初期のエンジニアは2名バックエンド1名, アプリ1名レビューなどのアドバイスに1名 • 不安材料は認証などの技術検証のみだったので、Flutterを選択 18 WHITE JACKアプリの技術選定

Slide 19

Slide 19 text

% • Flutter公式はMVVMを推奨 • 2024年7月頃に記事が出た https://docs. fl utter.dev/app-architecture/guide 19 今新規でFlutterアプリを作るなら

Slide 20

Slide 20 text

% • 画面間での共通の処理を書きやすい - onResume/onPause - ログ - Error handling • 画面ごとに捉えるので、 1画面を前提としたモバイルアプリとの相性がいい • サンプルが多い 20 MVVMのメリデメ • 管理するプロパティが増えるごとに Stateが肥大化 - Loadingなどの状態管理が苦手 • 宣言的UIとの相性が良くない • Riverpodの思想とは異なる - StateNoti fi erがv2で非推奨にメリットデメリット

Slide 21

Slide 21 text

% • 宣言的UIとの相性が良い UI = f(state) • 最小コンポーネントごとに状態を管理しやすい(再利用性UP) • Stateごとに単一管理になるので処理が明確 21 Riverpodアーキテクチャのメリデメ • 画面ごとの処理は工夫が必要 • Ephemeral stateに使うと冗長になりやすい • 1度だけの処理等が難しい • Unit testが若干複雑 • DIと状態管理の機能が混ざりがちメリットデメリット ※ 設計とライブラリとしてのデメリットが混在しています

Slide 22

Slide 22 text

% • 宣言的UIの大先輩 Reactの解決策を参考にする • Riverpodの開発者RemiさんもReactの思想を参考にしている 22 Reactを参考にしてみる https://x.com/remi_rousselet/status/1896308668855161089

Slide 23

Slide 23 text

% • Ephemeral(local) stateを fl utter_hooksで管理 • App(global) stateをriverpodで管理 • WHITE JACKアプリでは fl utter_hooks + riverpod を採用 23 新規アプリで採用した設計

Slide 24

Slide 24 text

% • 宣言的UIとの相性が良い UI = f(state) • 最小コンポーネントごとに状態を管理しやすい(再利用性UP) • State呼び出しのロジックを共通化できる 24 hooks + riverpodのメリデメ • 画面ごとの処理は工夫が必要 • (現状)ネットにあまり情報がない • hooksにロジックが入るとテストが難しいメリットデメリット

Slide 25

Slide 25 text

% • ロジックはUseCaseに記述して、基本的にUnit testを書く 25 実際のアーキテクチャ図 https://www.m3tech.blog/entry/2025/07/31/150000

Slide 26

Slide 26 text

% 26 https://docs. fl utter.dev/app-architecture/guide#optional-domain-layer

Slide 27

Slide 27 text

% • Riverpod v3からmutationなどが追加され、よりTanstack Query Likeに • Ephemeral stateにriverpodを使うのはToo muchだったので hooksにしていたが、riverpodに統一し直すのはアリ • 画面間の共通処理の最適解がまだ思い浮かんでいない 27 改善点

Slide 28

Slide 28 text

% • Riverpod v3からmutationなどが追加され、よりTanstack Query Likeに • Ephemeral stateにriverpodを使うのはToo muchだったので hooksにしていたが、riverpodに統一し直すのはアリ • 画面間の共通処理の最適解がまだ思い浮かんでいない 28 改善点まとめ最近の取り組み WHITE JACKの例デジスマの例 M3の紹介 Findy Job Lunch Talk

Slide 29

Slide 29 text

% • E2Eテスト(Maestro)をフルで導入 → 少人数チームでもQAコストを大幅削減 • Unit test & E2E test & AI code review → いつでもデグレに気がつける状態に • Figma MCP & AI coding → Figmaのコンポーネント定義を、コード上のコンポーネント定義と合わせる 29 最近の取り組み

Slide 30

Slide 30 text

% • E2Eテスト(Maestro)をフルで導入 → 少人数チームでもQAコストを大幅削減 • Unit test & E2E test & AI code review → いつでもデグレに気がつける状態に • Figma MCP & AI coding → Figmaのコンポーネント定義を、コード上のコンポーネント定義と合わせる 30 最近の取り組みまとめ最近の取り組み WHITE JACKの例デジスマの例 M3の紹介 Findy Job Lunch Talk

Slide 31

Slide 31 text

% • 2025年から新規で作るなら、(個人的には) hooks + riverpod • 2026年春くらい? = Riverpod v3が成熟してくなら全部Riverpodに寄せるのは(個人的には)アリかも • MVVMも(個人的には) 悪くはないと思っている ※ Riverpodを使って実現するなら注意が必要 • 結局はUDF(Unidirectional Data Flow:単方向データフロー)になってさえいればいい → Riverpodを使わずに、Providerだけでも全然アリ 31 まとめ