Architecture: Entities - MAD Skills
URL:https://www.youtube.com/watch?v=cfak1jDKM_4
一言で表すと
概要
各レイヤー毎に1つ以上の個別のエンティティを作成することが推奨される
関心事が異なり、レイヤー固有の属性を必要とすることがある
データレイヤーとUIレイヤーで分ける
よくあるケース
Remote Entities
apiのjson model等
Database Entities
アプリケーション内のDBのmodel
Domain Entities
ドメインレイヤーが存在するなら
ビジネスモデルと呼ばれる
UiState
画面ごとの状態Model
なぜ分けるのか?
Remote EntitiesとDatabase Entitiesを一緒にした場合
一部のデータはDBに保存したくないときに大変なことになる
tokenはセキュリティ的に保存したくない
別のテーブルとして保存したいデータ
永続化の必要がないデータ
https://scrapbox.io/files/627baa6bf2c1ce0023ea4fba.png
chigichan24.icon @Ignoreすき
分けてそれぞれで必要なデータだけを扱ったほうが好ましい
ドメインレイヤーを分ける
別モジュールに分けるとより良い
ビルド時間が改善される
他プラットフォームと共有できる
ドメインレイヤーはオプション
UIレイヤーでUIモデルを定義するでも良い
Parcelableに渡すデータを減らす
api responseではなく、必要なデータを使うことで、Parcelableのデータを最小限にすることができる
mayamito.icon over fetchみたいな話かな(APIレスポンスにはViewにとって余分なデータも含まれてるみたいな)
RecyclerViewの例
selected のようなUI状態も定義ができる
https://scrapbox.io/files/627bac4f47c962002049c578.png
効率的な差分更新にも役に立つ
他の利点
APIの差し替え等のAPIの変更はAPIだけで行うことができる
UIの変更はUIだけで完結する
デメリット
開発時間が伸びる
複数Entityがあると開発者間で混乱する
マッピングがめんどくさい
https://scrapbox.io/files/627bad1ee57c440022b5b5c3.png
Mori Atsushi.icon 🤔
chigichan24.icon code gen を導入できるところには導入しような
RyuNen344.icon人間はドキュメントを読まないんだよなぁ・・・・・
mayamito.icon 人間は愚か
気になるポイント
Mori Atsushi.icon UiStateでドメインオブジェクトを持っても良いか
例では持ってるように見える
Composeで@Stable, @Immutableのアノテーションをドメインオブジェクトにつけたくない
Mori Atsushi.icon UseCase / Repository専用のmodelを作りたくなるんだけどどこまでするのがいいんだろう…?
メモ
コメント