親和性の高いMVVMにする。考え方を適用させます。レイヤー分けとその特徴としては以下のようにします。・バックグラウンドActivityはシングルアクティビティ。アプリのフロントバックのハンドリングとフラグメント管理を行う。Activityを1つにすることでActivityバックスタックの仕様とActivity起動モードを意識しなくてよくするため。ActivityとFragmentは両方ともUIコントローラという側面があるので、UIはFragmentが持つという方針にすることで、Activityとの役割を明確にして開発の迷いをなくすため。1画面1Fragment。画面遷移はNavigationComponent。DataBindingは使わない。レイアウトファイルにはViewModelを依存させないため。データのオブザーブはフラグメントで行う。ドメイン(ビジネスロジック・プレゼンテーションロジック)基本的にビジネスロジック・プレゼンテーションロジックはViewModelが持つ。このレイヤーで使うDTO、VOが実質このアプリのエンティティの位置付けとなる。より引数を扱いやすくする、仕様を隠蔽しやすい、などの利点を持つ。データのやり取りはLiveDataを使う。Fragment、Activityとのやり取りが、ライフサイクル仕様を考慮して安全に連結できるため。可能であればRxは使わない。LiveDataとの使い分けがわかりにくいため。ObservableField系もデータバインディングを使わないので、実質使わない。Serviceなどのバックグラウンドからのビジネスロジック処理はProviderというクラスを作り、そこにアクセスする。ViewModelに統一しようかと悩んだが、バックグラウンドはViewではないので。ネーミングもUseCaseにしようかと考えたが、基本がMVVMなのでCleanArchitectureと混同するとわかりにくくなるかと思い、Providerというネーミングにした。(FlutterではProviderというのがあるので、それを参考にネーミングしました。)リポジトリレイヤーに依存しないために、RepositoryIFを作りRepositoryレイヤーのクラスはこれを実装する。このあたりがCleanArchitectureの要素で、継承することで依存関係逆転させて「ドメイン(上位レイヤー)に対してのみ依存の方向を向ける」をしています。リポジトリ(データアクセス)API、データストア、PreferenceへのアクセスをRepositoryパターンを使ってアクセスする。ユニットテスト対象ドメインレイヤーとRepositoryレイヤーをユニットテスト対象とし、ビューレイヤーは変更頻度の高さとテスト難易度を考慮して対象としません。ドメインレイヤーとRepositoryレイヤーもすべてを対象とするわけではなく、効果の高いところのみを対象とします。所感クライアント・サーバーモデルを前提とすると、アプリでは安定度の高いビジネスロジックは意外と限られてくるなぁというイメージでした。センサーなどデバイスに依存するようなロジックはアプリに依存するため安定度の高いビジネスロジックになる可能性が高いですが、ビューに依存するロジックはどうしてもビューの変更に依存して安定度が低くなるイメージでした。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。