スケールするFlutterアプリアーキテクチャで開発させてもらいました🙇‍♂️

前職のアーキテクチャをざっくり紹介したいな、と思いました。かなり開発体験良かったもので。。。

設計された方は僕が入社した際には既に退職されていました。ドキュメントが残されていたり、当時のメンバーが残っていたので理解するのは難しくなかったです。

こんな感じです。

plain old dart immutable objectの略で基本どこからでも呼んでOK（と理解）です。 PODIOに設定するメソッドはデータの提出系のみでロジックはNGでした。

POJOから由来しており、PODIOは「何にも依存しないアプリ内で動くために存在するオブジェクト」と理解していました。

役割はトランザクションスクリプトで、後述するStoreに副作用を与えることができる唯一の存在です。ロジックは基本的に全てBehaviorになります。

あくまで手続きをまとめるという粒度で、「Behaviorがそのままユースケースになる」こともあれば「アプリケーション内で必要な手続きをまとめる」ことも許されていました。つまり、BehaviorがBehaviorを呼び出すのは問題ないというルールでした。

後述するRepositoryを呼び出すのもBehaviorの役割です。

FluxのStoreとほぼ同義です。アプリの状態を管理するためのオブジェクトです。

アンチパターンとしてはViewと1:1になってしまうことです。 StoreとViewは1:Nとなりviewを更新する対象も自由自在です。

データ永続化を行います。

基本的にBehaviorからのみ呼び出します。

PODIOは正規化してMap<Id, User>で保持したりするなど他にも細かなルールはあります。

下記がアーキテクチャを発案した方の原文です。

Kinokのブログ