アプリ アーキテクチャ ガイドの解説
URL:https://www.youtube.com/watch?v=ffH-fkgz3Hg
一言で表すと
概要
クリーンアーキテクチャはデザインパターンではない
よく見るレイヤーの図も模範事例の一つにすぎない
Googleのアーキテクチャガイドはすべてのパターンやアーキテクチャを網羅するものではない
なぜドメイン層が重要なのか
UI層とデータ層の仲介がないときに生じる設計上の問題を解決できる
UI層に集中しすぎると画面の区別を超える対応が難しくなる
データ層に集中しすぎるとデータスキーマがUI層まで影響する
Androidエンジニア的にはオブジェクト指向設計の観点で見るとAndroidの設計は簡単すぎるのでオブジェクト指向モデリングなどを試した例や経験が足りない
mayamito.icon 🤔
データ・エンティティ中心の思考では良い設計ができない
核心の行為とactorを抽象化する形が重要
しかし、モバイルアプリにおけるこれらのロジックが多いかと言われるとそうでもない
ほとんどのドメインロジックはバックエンドにあるのでDDDはファット
chigichan24.icon case by case
UseCaseを利用する形
トランザクションスクリプトというアンチパターンに近い形になってしまう
non-domain mediator layerを用意する形
Gateway, Mapper, Data Controller, Translator
データ層で吸収する形
Repository
Repository pattern
ドメイン層またはUI層から呼び出されるための抽象を提供
データ格納に関する具体的な事項を隠す
Data Source
IOの詳細を隠す
データ層の考慮事項
CRUD類だけの簡単な操作だけならRepository/Data Source 両方必要ないかも
AAC ViewModel
Androidにおける一般的な実装に役立つ最小限の機能を提供
状態管理
coroutine scope
依存性注入(via Dagger Hilt)
Helper for Navigation
Jetpack ComposeにおいてのViewModelを考える
ほんとに要る?
mayamito.icon わかる〜
rememberSaveable: AAC ViewModelが提供していたstateをView側で定義可能
データ層のRepositoryがViewと違うlifecycleを持っている場合
そもそもstateの格納をViewModelに委任する必要があるのか
ViewModelがなくてもよく動作する場面が多い
ドメイン or データレイヤが十分なビジネスルールを実装していてかつAAC VMの便利機能がいらない場合
気になるポイント
メモ
コメント