#RAKUSMeetup ©2022 RAKUS Co., Ltd. アプリアーキテクチャを明文化して チームの開発効率をアップ Android アーキテクチャを 明文化して臨んだ新規開発を振り返る @akkiee76

#RAKUSMeetup 自己紹介 Akihiko Sato / 株式会社ラクス Lead Engineer / @akkiee76 SaaS 開発 (Backend, Frontend) / Mobile 開発 (iOS, Android) 上流工程、コードレビュー、チームの課題改善など 読書 / コーヒー / HHKB / 腹筋ローラー・体幹トレーニング

#RAKUSMeetup 今日伝えたいこと アーキテクチャを明文化して 得られたことと今後に向けての課題

#RAKUSMeetup 背景 楽楽精算では、現在 Kotlin 版と Cordova 版の 2つの Android アプリをリリースしています。 これまで Kotlin 版では、最新の Android バージョンに追従してき ましたが、Cordova 版では FW の対応の遅れにより、 タイムリーな対応が難しい状況でした。

#RAKUSMeetup 背景 他にも ・　セキュリティリスクの懸念 ・　Cordova 開発者減少といった採用面での課題 といった背景もあり、 Cordova から Kotlin へリプレースすることに

#RAKUSMeetup Android チームの現状 現在のチームは、 ・　Android 開発のナレッジが少ない 　 ・　新規アプリの開発経験がない という課題があり、 新規案件開発の苦戦は目に見えていました。

#RAKUSMeetup 現状へのアクション そこで、開発の推進を目的としたアクションとして アーキテクチャを選定し、明文化することにしました。

#RAKUSMeetup アーキテクチャ選定にあたって① アーキテクチャ選定の観点として ・　Android 公式アーキテクチャ ・　モダンアーキテクチャは技術的に扱えない可能性 オーソドックスな MVVM アーキテクチャを採用することに。

#RAKUSMeetup アーキテクチャ選定にあたって② MVVM アーキテクチャは 2017 年位から RxJava を中核に DataBinding アーキテクチャとして広まったアーキテクチャです。 Jetpack Compose などの今後の展望を考えると、 Android 標準アーキテクチャである MVVM アーキテクチャは、 今後も運用しやすいアーキテクチャであると考えました。

#RAKUSMeetup アーキテクチャ選定にあたって③ また、アーキテクチャを検討する上で ・　関心の分離を重要原則とする ・　クラスの責務をできるだけシンプル／コンパクトに保つ ・　各クラスのテストの容易性を向上させること を大方針とすることに。

#RAKUSMeetup ここからは 実際に明文化した内容を紹介します。

#RAKUSMeetup 1. アプリケーションレイヤー構成 基本的なレイヤー構成として、 3層レイヤー構成を採用。 　・ Presentation Layer 　・ Domain Layer 　・ Data Layer それぞれを役割を定義します。

#RAKUSMeetup Presentation Layer（プレゼンテーション層） プレゼンテーション層は、ユーザーに情報を表示し、入力を受け付ける機能を 持っています。具体的には、ユーザー操作や外部入力（レスポンス）によってデー タが変更されるたびに、変更された情報を反映するよう UI を更新する必要が あります。 主にプレゼンテーション層は、Activity、Fragment、ViewModel や BindingModel に変換するための Converter などを配置します。また、 RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼン テーション層に配置します。

#RAKUSMeetup Domain Layer（ドメイン層） ドメイン層は、複雑なビジネスロジックや複数の ViewModel で再利用される 単純なビジネスロジックが隠蔽（カプセル化）されたレイヤーです。 ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の ロジックをこのレイヤーに実装します。また、各ユースケースでは異なるビジネス ロジックが集約されるため、それぞれのユースケースクラスは疎であることが アーキテクチャとして重要です。

#RAKUSMeetup Data Layer（データ層） データ層は、アプリで扱うデータに関連するロジックが集約されます。具体的に は、アプリで使用するデータの作成、保存、変更方法（APIに関するものを含む） を決定する実際のロジックで構成されることがこのレイヤーの期待です。 データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジト リで構成されます。また、アプリで処理するデータの種類ごとに Repository を作成する必要があります。

#RAKUSMeetup 2. Package 構成

#RAKUSMeetup 3. 基本クラスに各ルールを明文化 ・Activity ・Fragment ・ViewModel ・UseCase ・Repository ・責務 ・命名規則 ・ルール（制約） ・実装例 ・テストで確認すること ・テスト実装例 明文化 明文化した各ルールを適用したサンプルプロジェクトも用意

#RAKUSMeetup 2ヶ月程度で開発完了 振り返ってみると・・・

#RAKUSMeetup 実践してよかったこと 1. チームの技術力が向上 　　・　オブジェクト指向の成長 2. 設計の議論をすることが少なく、開発に注力できた 　　・　チームの生産性が高まった （見積に対しての実績） 3. クラスの責務を小さくしたため、テストが描きやすかった 　　・　テスト品質の担保

#RAKUSMeetup 実践してイマイチだったこと 1. メンバーによって理解度がバラけた ・　事前の学習コスト（準備コスト）がやや不十分だった 2. ライブラリ選定がややモダンだった ・　新しいライブラリ・フレームワークを利用する実装コスト

#RAKUSMeetup 技術的課題 技術駆動パッケージング* による参照関係 　　・　横断的に利用されるクラス・コンポーネントの配置 　　・　package private を維持できない * 設計パターンによるフォルダ分け

#RAKUSMeetup 技術的課題イメージ NetworkErrorはPresentation Layerに配置されているが、 通信時にcatchされ、Fragment（View）でダイアログ表示のため、 各層から参照されてしまっている。 このように層を跨いで参照されて いるクラスが存在してしまった。

#RAKUSMeetup 技術的課題へのアプローチ 1. TOPレベルでの各層に分けるパッケージングをやめ、ドメインを ベースとしたパッケージング構成に変更する 2. どの層からも参照される抽象的なクラスは、 マルチプロジェクト構成にして アプリケーションから参照させる 機能拡張に伴い、更なる問題も・・・

#RAKUSMeetup 技術的課題へのアプローチ Before After

#RAKUSMeetup まとめ アーキテクチャを明文化すると、 1. チームの技術力の向上 2. 開発の生産性向上 3. 品質向上 といった恩恵を受けることができます。

#RAKUSMeetup まとめ また、開発中に発生する技術的負債を解決することで、 よりチームの技術力の向上に繋がります！ チームでトライしてみてはいかがでしょうか。

#RAKUSMeetup ご静聴ありがとうございました