Riverpod 移行を支えた LivMap のアーキテクチャ

Findy 主催「Flutter技術構成を紐解く クロスプラットフォーム開発の裏側」の LT 資料です。

https://findy.connpass.com/event/331062/

Transcript

1. Riverpod 移行を支えた LivMap のアーキテクチャ ちゅーやん（中條 剛） @chooyan_i18n
2. https://livmap.co/
3. View input / output BusinessLogic データの流れ Repository データベース操作 LivMap のアーキテクチャ（ざっくり） 依存の方向
4. 課題から考える 副業参加のメンバーが多い テストの体制が薄い 同機能の別アプリを作りたい バックエンドの役割が薄い Firebase が使えない別アプリがあり得る リアルな移動を伴うメイン機能がある いずれは Riverpod に移行する ルールは最小限にする 自動テストの書きやすさを考える View を分離する BusinessLogic をひとつの層として設ける Repository を差し替え可能にする GPS を差し替え可能にする 状態管理パッケージは View のみが依存する から から から から から から から
5. View Business Logic Repository LivMap のアーキテクチャ （もう少し広い目で） Provider
6. View Business Logic Repository Riverpod 移行 Provider
7. View Business Logic Repository Riverpod 移行
8. Riverpod 移行 • View のみの修正 • 機能ごとの違いはほぼ影響無し • 「アプリ全体書き直し」感はなかった！ • 依存関係を整理すると修正範囲を限定できる、を体験できた
9. 課題 • 日々の開発に活かせていない ◦ ❌ とりあえず守ってもらう ◦ 🙆 開発効率アップに活用する • 守れていない部分も多々ある • 「テストが書きやすい」≠「テストが書けている」
10. “最適なアーキテクチャは変化するもの” ご清聴ありがとうございました
11. あわせて読みたい https://zenn.dev/chooyan/articles/eefc76dbd2ba25