日経電子版 for Androidにおける ドメインレイヤ（ユースケース）の実装方針について

Transcript

1. 2023/6/15 横山朝海(@yokomii) 日経電子版 for Androidにおける ドメインレイヤ（ユースケース）の実装方針について NIKKEI TECH TALK #8 1
2. 2 ドメインレイヤ
3. ハッシュタグ #nikkei_tech_talk • クリーンアーキテクチャやオニオンアーキテクチャにおけるドメイン層のこ とではありません🙇 • Androidの推奨アーキテクチャガイドラインにおけるドメインレイヤです ◦ https://developer.android.com/topic/architecture/intro ◦ 日経電子版 Androidアプリではこの推奨アーキテクチャを設計の基 本指針としています ドメインレイヤ 3
4. ハッシュタグ #nikkei_tech_talk Android 推奨アーキテクチャ 4 • 推奨アーキテクチャにおける共通原則 ◦ 関心の分離 ◦ 永続データモデルによるUI操作 ◦ SSOT ◦ 単方向データフロー（UDF） • 上記共通原則を考慮した上で、2層（UI、データ） 以上のレイヤードアーキテクチャを推奨 ◦ ドメインレイヤはオプショナル
5. ハッシュタグ #nikkei_tech_talk データレイヤ 5 • アプリデータの作成、保存、変更のためのビジネ スロジック群 • データソース ◦ アプリとシステム（ネットワーク、ローカルDBな ど）間のデータの橋渡しをする • リポジトリ ◦ データ管理のためのビジネスロジックを有す る ◦ 上位レイヤにデータを公開する
6. ハッシュタグ #nikkei_tech_talk UIレイヤ 6 • データレイヤから取得したデータを表示するため のレイヤ • UI状態ホルダ（ViewModel） ◦ 下位レイヤからデータの取得 ◦ UI状態の生成・保持 ◦ UI操作によって適切なビジネスロジックを呼 び出す • UI要素（View、Jetpack Compose） ◦ UIをレンダリング
7. ハッシュタグ #nikkei_tech_talk 🌟ドメインレイヤ 7 • UIレイヤとデータレイヤの間に位置するレイヤ • 複雑なビジネスロジックや、複数のUI状態ホルダ で再利用される単純なビジネスロジックをカプセル 化した「ユースケース」クラスを内包
8. ハッシュタグ #nikkei_tech_talk ユースケース 8 • ビジネスロジックをカプセル化したクラス ◦ 1ビジネスロジックにつき1クラスの単位で実 装 • その他ガイドライン上の推奨事項 ◦ 命名規則 ▪ 動詞の現在形 + 対象 + UseCase ◦ ライフサイクルを持たない ▪ 毎回新しいインスタンスを生成 ▪ 状態(可変データ)を持たない ◦ メインセーフ
9. ハッシュタグ #nikkei_tech_talk ユースケース 9 • ユースケースクラスを設ける利点 ◦ 共通ロジックをカプセル化することでボイラー プレートコードの回避 ◦ ロジックを外部クラスに切り出すことで、ケー スを使用するクラスの可読性の向上 ◦ 1クラスで1ビジネスロジックだけに集中するこ とでコードがシンプルになり、テストが書きや すい
10. ハッシュタグ #nikkei_tech_talk ユースケース 10 • システムの振る舞いの中核を担う、クリーンアーキテクチャのユースケースとは別物 • あくまでビジネスロジックをカプセル化することで、コードの複雑さを減らすことが目的 • 推奨事項がいくつか存在するが、様々なアプリに適用しやすいようにあえて厳格なルールは設けられ ていない⇨自由実装になりがち • 👉 ガイドライン以上の細かな方針を各アプリで定めることが重要！！ https://developer.android.com/jetpack/guide/domain-layer
11. 11 日経電子版 for Androidにおける ユースケースの実装方針🧭 (推奨ケース・非推奨ケース)
12. 12 🙆推奨ケース
13. ハッシュタグ #nikkei_tech_talk 🙆推奨ケースその1 13 複数リポジトリ処理を組み合わせる • (公式ガイドラインでも紹介されているケース) • 複数リポジトリからの取得値を別の値に変換して 返すなど • ユースケースはUIレイヤとデータレイヤの間に位 置するので、UI状態ホルダとリポジトリの中継処 理をすることが多い
14. ハッシュタグ #nikkei_tech_talk 🙆推奨ケースその2 14 単一リポジトリ内の複数処理を組み合わせる • (このようなビジネスロジックは大体リポジトリ側で 吸収できるはず) • アプリ特有の関数の実行手順がある場合などに ユースケースで吸収 ◦ 例えばWearとモバイルで共通のリポジトリを 用いているが、リトライ回数に違いがあるとき など
15. ハッシュタグ #nikkei_tech_talk 🙆推奨ケースその3 15 再利用されるビジネスロジック • (公式ガイドラインでも紹介されているケース) • UIレイヤで繰り返し発生するロジックをビジネスロ ジックとしてカプセル化する • 公式ガイドではUtilクラスの代替としてユースケー スを用いることを推奨 ◦ Utilクラスは1クラスに複数ビジネスロジックが 含まれることで肥大化し煩雑になりがち ◦ 反面ユースケースは1クラス1ロジックかつ、ク ラス名によって処理内容が明瞭
16. 16 🙅非推奨ケース
17. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその1 17 リポジトリの関数を呼ぶだけのケース • UIからリポジトリの直接参照を禁止する場合に、 その中継を担うためのケース • リポジトリ参照を制限をするメリット ◦ UIでデータ取得する際に必ずユースケースを 経由するのでコードの一貫性が保たれる ◦ リポジトリに含まれる全ての関数がUIに公開 されなくなる
18. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその1 18 リポジトリの関数を呼ぶだけのケース • 日経電子版のデータレイヤの特徴 ◦ 扱うデータの種類が多い ◦ リポジトリの関数の種類が多い ▪ サービスを長期運用する中でどんどん数 が増えていった • 関数呼び出しごとにクラスを設けた場合にクラス 数が膨大になりすぎる ◦ 先にデータやリポジトリ関数の整理が必要 • ↑のため、UI状態ホルダがリポジトリを直接参照す ることを制限せず、このようなケースは一旦不要と した
19. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその2 19 モデルデータをUI状態に変換 • UI状態 ＝ モデルデータをUIがレンダリングしやす い形式に加工した状態 ◦ ref: https://developer.android.com/topic/archite cture/ui-layer#define-ui-state • UI状態をカプセル化したクラスはUIレイヤに定義 している ◦ 下層であるドメインレイヤからは参照できない • よってUI状態はUIレイヤの関心ごと⇨変換はUIレ イヤでやる
20. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその3 20 Resultクラスを戻り値とするビジネスロジック • 当初、kotlin.Resultや自作のResultクラスで実行 結果をラップして値を返すようなケースを認めてい た • ←のようなコードでは、CancellationExceptionを 握りつぶしてしまうので呼び出し元のコルーチンが 正常に中断されなくなる • 意図しないキャンセル例外の握りつぶしを防ぐた めにResultクラスの利用は非推奨とした ◦ FYI: kotlin-resultには runSuspendCatching()というこの問題を回避 する仕組みがある
21. ハッシュタグ #nikkei_tech_talk • Androidの推奨アーキテクチャは幅広いアプリ（iOSも👍）に適用しやすいように、あえて厳密にルー ル化されていない部分がある ◦ そのため、各アプリでより詳細な方針を定めることが重要 • 今回紹介した方針はあくまで電子版における内容であり、全てのアプリにおいて最適解ではないこと をご留意ください ◦ 開発規模や要件によって最適な戦略を探る🧐 • アプリ独自の方針が公式ガイドラインの指針から大きく外れないことを推奨 ◦ 公式の情報はエンジニア間で共通認識となりやすいので、そこに揃えておくと読み解きやすい コードになる • 皆さんの開発してるアプリでのユースケースの実装方針もぜひ教えてください🫶 まとめ 21
22. 22 ご清聴ありがとうございました🧏