#はじめに
###対象者

改定されたものの、忙しくてアーキテクチャガイドを熟読している暇などない人
読んでみたけども、何を言っているのか全く分からなかった人
アーキテクチャがなぜ必要なのか分からない人
設計の原理原則を知りたい人

#目次
内容は、主に3つです。

###1. 設計の必要性
###2. Googleが推奨している設計パターン
###3. ベストプラクティス集

#1.設計の必要性
###UXの注意点
Androidアプリケーションは、ユーザーとAndroidOSの事を考えて開発する必要があります。

ユーザーは、デバイス上のアプリを短時間の中で多くの操作を行うことがある。
モバイルのリソースは限られているため、AndriodOSの最適化処理によっていつでも強制終了する可能性がある。

これを想定した時に回避すべきなのは

コンポーネントがデータを持っていること
コンポーネント同士が依存関係にあること

##原理原則について
そのために、大事なことは「責務の分離」

####関心の分離

例えば、Activity/FragmentはUIの描画または、エントリポイントだけを担当します。
これにより、コンポーネントが独立して機能することに繋がり、さらに、テストのしやすさにも繋がる。

####データモデルからUIを駆動する

AndroidOSによるプロセスの最適化によって解放されたり、ユーザーによっては通信環境が悪かったりと状況は様々。

そこで、データは確実に保存/保持して、そこからUIを設計していきましょうということを言っています。

#2. Googleが推奨している設計パターン
さて、どのように責務の分離をしていくのが良いのかGoogleの見解を見てみましょう。

##UI Layer
データの表示を担当

###UI elements
「整形」
データをレンダリングをして、表示させます。
例）ViewやJetpackCompose

###State holders
「保持」
UIに関するデータやロジックを保持します。
例）ViewModel

##Data Layer
「公開」
データを不変な値で持ち、アプリに一貫したデータを他のレイヤーに公開する役割。

###Repository
「一元化」
データソースへのアクセスを一元化します。
（UI LayerからData Layerへのエントリポイント）
UI Layerは、データがどこからきているかを知りません。

###Data Sources
「操作」
データソースへの読み書きを行います。
つまり、アプリとデータソースとの仲介役ともいえます。
一つの情報源につき、一つのデータクラスを定義するのが良いです。

##Domain Layer
「集約」
いわゆる、ユースケース。

ViewModelの大量発生によるビジネスロジックの重複の回避などを担当。
ここは、optionとあるので必要に応じて責務を分けるのが良い。

#3. ベストプラクティス集
飛ばしましたが、依存関係を提供してくれるクラスを定義することでスケーリングに繋がります。
Androidでは、Hiltを用いることが推奨されます。

####コンポーネントは破棄されやすいので、そこでデータを保持しないこと
####Androidクラスへの依存を減らす（？：良く分からなかった・・）
####モジュールは、明確に分けて、なるべく独立させる
####車輪の再発明で労力を無駄にしない（Jetpack使ってね！むふふ・・）
####単体テスト可能にする
####通信状況が悪い時でもUXを維持するために、ローカルDBを出来る限り最新に保つ

##おわりに
いかがだったでしょうか。

次回は、UIレイヤーについて要約したいと思います。
##参考
https://developer.android.com/jetpack/guide?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-architecture%23article-https%3A%2F%2Fdeveloper.android.com%2Fjetpack%2Fguide