Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2023/06/15開催、NIKKEI Tech Talk #8登壇資料です #nikkei_tech_talk
タイトルは「日経電子版 for Android におけるドメインレイヤ(ユースケース)の実装方針について」です
https://nikkei.connpass.com/event/284090/

More Decks by 日本経済新聞社 エンジニア採用事務局

Other Decks in Technology

Transcript

  1. ハッシュタグ #nikkei_tech_talk Android 推奨アーキテクチャ 4 • 推奨アーキテクチャにおける共通原則 ◦ 関心の分離 ◦

    永続データモデルによるUI操作 ◦ SSOT ◦ 単方向データフロー(UDF) • 上記共通原則を考慮した上で、2層(UI、データ) 以上のレイヤードアーキテクチャを推奨 ◦ ドメインレイヤはオプショナル
  2. ハッシュタグ #nikkei_tech_talk データレイヤ 5 • アプリデータの作成、保存、変更のためのビジネ スロジック群 • データソース ◦

    アプリとシステム(ネットワーク、ローカルDBな ど)間のデータの橋渡しをする • リポジトリ ◦ データ管理のためのビジネスロジックを有す る ◦ 上位レイヤにデータを公開する
  3. ハッシュタグ #nikkei_tech_talk UIレイヤ 6 • データレイヤから取得したデータを表示するため のレイヤ • UI状態ホルダ(ViewModel) ◦

    下位レイヤからデータの取得 ◦ UI状態の生成・保持 ◦ UI操作によって適切なビジネスロジックを呼 び出す • UI要素(View、Jetpack Compose) ◦ UIをレンダリング
  4. ハッシュタグ #nikkei_tech_talk ユースケース 8 • ビジネスロジックをカプセル化したクラス ◦ 1ビジネスロジックにつき1クラスの単位で実 装 •

    その他ガイドライン上の推奨事項 ◦ 命名規則 ▪ 動詞の現在形 + 対象 + UseCase ◦ ライフサイクルを持たない ▪ 毎回新しいインスタンスを生成 ▪ 状態(可変データ)を持たない ◦ メインセーフ
  5. ハッシュタグ #nikkei_tech_talk ユースケース 9 • ユースケースクラスを設ける利点 ◦ 共通ロジックをカプセル化することでボイラー プレートコードの回避 ◦

    ロジックを外部クラスに切り出すことで、ケー スを使用するクラスの可読性の向上 ◦ 1クラスで1ビジネスロジックだけに集中するこ とでコードがシンプルになり、テストが書きや すい
  6. ハッシュタグ #nikkei_tech_talk 🙆推奨ケースその3 15 再利用されるビジネスロジック • (公式ガイドラインでも紹介されているケース) • UIレイヤで繰り返し発生するロジックをビジネスロ ジックとしてカプセル化する

    • 公式ガイドではUtilクラスの代替としてユースケー スを用いることを推奨 ◦ Utilクラスは1クラスに複数ビジネスロジックが 含まれることで肥大化し煩雑になりがち ◦ 反面ユースケースは1クラス1ロジックかつ、ク ラス名によって処理内容が明瞭
  7. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその1 17 リポジトリの関数を呼ぶだけのケース • UIからリポジトリの直接参照を禁止する場合に、 その中継を担うためのケース • リポジトリ参照を制限をするメリット

    ◦ UIでデータ取得する際に必ずユースケースを 経由するのでコードの一貫性が保たれる ◦ リポジトリに含まれる全ての関数がUIに公開 されなくなる
  8. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその1 18 リポジトリの関数を呼ぶだけのケース • 日経電子版のデータレイヤの特徴 ◦ 扱うデータの種類が多い ◦

    リポジトリの関数の種類が多い ▪ サービスを長期運用する中でどんどん数 が増えていった • 関数呼び出しごとにクラスを設けた場合にクラス 数が膨大になりすぎる ◦ 先にデータやリポジトリ関数の整理が必要 • ↑のため、UI状態ホルダがリポジトリを直接参照す ることを制限せず、このようなケースは一旦不要と した
  9. ハッシュタグ #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レ イヤでやる
  10. ハッシュタグ #nikkei_tech_talk 🙅非推奨ケースその3 20 Resultクラスを戻り値とするビジネスロジック • 当初、kotlin.Resultや自作のResultクラスで実行 結果をラップして値を返すようなケースを認めてい た •

    ←のようなコードでは、CancellationExceptionを 握りつぶしてしまうので呼び出し元のコルーチンが 正常に中断されなくなる • 意図しないキャンセル例外の握りつぶしを防ぐた めにResultクラスの利用は非推奨とした ◦ FYI: kotlin-resultには runSuspendCatching()というこの問題を回避 する仕組みがある
  11. ハッシュタグ #nikkei_tech_talk • Androidの推奨アーキテクチャは幅広いアプリ(iOSも👍)に適用しやすいように、あえて厳密にルー ル化されていない部分がある ◦ そのため、各アプリでより詳細な方針を定めることが重要 • 今回紹介した方針はあくまで電子版における内容であり、全てのアプリにおいて最適解ではないこと をご留意ください

    ◦ 開発規模や要件によって最適な戦略を探る🧐 • アプリ独自の方針が公式ガイドラインの指針から大きく外れないことを推奨 ◦ 公式の情報はエンジニア間で共通認識となりやすいので、そこに揃えておくと読み解きやすい コードになる • 皆さんの開発してるアプリでのユースケースの実装方針もぜひ教えてください🫶 まとめ 21