昨日の記事でも書きましたが、アプリをリリースしました（現在、Android向けのみ）

この際に、どのようなアーキテクチャを採用して開発をするか悩みました。

Web上を色々と見てみた感じでは、MVVMを採用しているのが主流っぽいです（あくまで自分の観測で、ですが…）。

ただ、非常に個人的な話ではありますが、MVVMを導入するときに、バインディングの仕組みを個別のView、ViewModelにゴリゴリ自前で書いていくのがなんとなくしっくりこないというのがあります。

また、宣言的UIに値の更新時のリアクティブな反映はすでに組み込まれており、自前であえてバインディングを組み込むのか？という疑問もありました（このときは知りませんでしたが、後々調べるとSwiftUIの議論としてすでにかなり盛り上がったものでした*1）。

そこで、もう少し深堀りして検討することにしました。

なんのためにアーキテクチャの採用を考えるのか？

そもそも（アプリ開発で）アーキテクチャを採用するときに、なぜアーキテクチャを導入して開発しようとするのかというところを考えてみました。

MVCやMVP、MVVM、Fluxなどは「状態管理」「状態のUI等への反映」「UI／インフラレイヤー」を分離して、それらの間のデータの流れを定義することに主眼が置かれているように感じます。それにより、アプリケーション開発において「責務の異なる部分の分離をした上で、データの流れをどのような仕組みにするかを決める」ためである、といえるのではないかと思います。

アーキテクチャの選定

ここまで考えた上で、個人開発のFlutterアプリで採用するアーキテクチャとして何が良いかでいうと、以下で考えると良さそうでした。

構成が複雑すぎない
Flutterの宣言的UIの特性にあっている
データの流れがシンプルである

この視点で考えると、クリーンアーキテクチャに当たるようなドメインレイヤーの分離を詳細に定義しているアーキテクチャは、今回考えている個人開発レベルでは重厚長大になりそうだったため、やめました（あと、今回のアーキテクチャ選定としては、そもそもUIとControllerとのデータのやり取りの詳細が関心事なので少しズレている）。ドメインロジックがしっかりと入り込む場合であれば、検討してもよいかと思います。

クリーンアーキテクチャ
 引用元：Clean Coder Blog

また、具体的なアーキテクチャを考えてみると、Flutterの宣言的UIの特性から考えると、MVC、MVP、MVVMなどよりは、Fluxのほうが向いているように感じました。

とはいえ、Fluxの場合に、Action Creator => Dispatcher => Store => Views => Action Creator => ... のような流れになるのですが、Riverpodなどを採用した場合にDispatcherとStoreがNotifierに集約されている形になるので、Flux？というところに悩ましさを感じました。

Fluxアーキテクチャ