アーキテクチャを明文化して臨んだ新規アプリ開発戦略

「After DroidKaigi LT Night」2023/09/25の登壇資料です。

Transcript

1. ©2023 RAKUS Co., Ltd. アーキテクチャを明文化して臨んだ 新規アプリ開発戦略 After DroidKaigi LT Night 2023/09/25 @akkiee76
2. Akihiko Sato 株式会社ラクス 楽楽精算開発 iOS / Android / バックエンド @akkiee76 自己紹介
3. 既存アプリのリプレース案件で 実際に行なった開発戦略 😃
4. リプレースの背景 弊社１アプリのフレームワークとして Cordova を使用 • Cordova Android の開発が遅延 ◦ 新バージョン、API への対応の遅れ • Cordova 自体の EOL リスク ネイティブアプリとしてリプレースすることに
5. 開発に向けてのチーム課題 • Android ネイティブアプリのナレッジが少ない • 新規アプリ開発の経験がない リプレース案件の苦戦が明らか・・・ 😕
6. アーキテクチャを確立し ガイドラインとして明文化しよう😃
7. アーキテクチャ選定にあたって • モダンなアーキテクチャは学習コストが大きい • 開発のスケジュールもタイト オーソドックスな MVVM アーキテクチャを採用 （Compose の採用は見送りに） https://developer.android.com/jetpack/guide
8. 設計の基本原則 ガイドライン作成にあって以下を基本原則に • 「関心の分離（単一責任の原則）」を重要原則とする • クラスの責務をできるだけシンプル／コンパクトに保つ • 責務の細分化により、テスト容易性を向上させる
9. では、明文化した内容を一部紹介します😃
10. レイヤー構造 ３層レイヤー構造を採用し定義を記載 • Presentation Layer • Domain Layer • Data Layer https://developer.android.com/jetpack/guide
11. Presentation Layer の定義 プレゼンテーション層は、ユーザーに情報を表示し、入力を受け付ける機能を 持っています。具体的には、ユーザー操作や外部入力（レスポンス）によって データが変更されるたびに、変更された情報を反映するよう UI を更新する必要 があります。 主にプレゼンテーション層は、Activity、Fragment、ViewModel や BindingModel に変換するための Converter などを配置します。また、 RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼンテーショ ン層に配置します。
12. Domain Layer の定義 ドメイン層は、複雑なビジネスロジックや複数の ViewModel で再利用される単 純なビジネスロジックが隠蔽（カプセル化）されたレイヤーです。 ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の ロジックをこのレイヤーに実装します。また、各ユースケースでは異なるビジネ スロジックが集約されるため、それぞれのユースケースクラスは疎であることが アーキテクチャとして重要です。
13. Data Layer の定義 データ層は、アプリで扱うデータに関連するロジックが集約されます。具体的に は、アプリで使用するデータの作成、保存、変更方法（APIに関するものを含 む）を決定する実際のロジックで構成されることがこのレイヤーの期待です。 データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジト リで構成されます。また、アプリで処理するデータの種類ごとに Repository を 作成する必要があります。
14. Package 構成を定義
15. 基本クラスの各ルールを記載 ・Activity ・Fragment ・ViewModel ・UseCase ・Repository ・責務 ・命名規則 ・ルール（制約） ・実装例 ・テストで確認すること ・テスト実装例 明文化 各ルールを適用したサンプルプロジェクトも用意
16. 開発完了後に 振り返ってみると・・・
17. 良かったこと ✅ チームの技術力が向上 　・オブジェクト指向の成長 ✅ 設計の議論をすることが少なく、開発に注力できた 　・チームの生産性が 20% 向上 ✅ クラスの責務を小さくしたため、テストが実装しやすかった 　・テスト品質の担保
18. イマイチだったこと 🚫 アプリ規模に対してファイル数が多くなる 　・責務を細かく分けすぎてしまった 🚫 メンバーにより理解度の乖離が出てしまった 　・ガイドラインを作成しても実践するための学習コストは必要 🚫 package 構成を各レイヤーで限定しすぎてしまった 　・レイヤーを跨いで使用するクラスの置き場に困る（後述）
19. package 構成の技術的課題 「NetworkError」のようにレイヤーを跨いで使用するクラスが複数登場 package private が望ましい
20. 課題へのアプローチ • アプリ本体はドメイン駆動の package 構造に変更 • マルチモジュールを採用し、どのドメインからも参照可能に
21. まとめ アーキテクチャの明文化により以下の恩恵を受けることができます • チームの技術力向上 • 開発の生産性アップ • 品質担保 チームでぜひトライしてみてはいかがでしょうか
22. Thank you !