SAM mascot
公開日

Jetpack Composeで実践するAndroid Clean Architecture

Authors
Jetpack Compose sample application

はじめに

このサンプルでは、Jetpack Compose、MVVM、Clean Architectureの考え方を使って、Androidアプリをどのように構成しているかを紹介します。実運用の複雑さを加える前に、依存関係、状態管理、テストの境界を理解しやすくするため、あえて小さな構成にしています。

ソースコードはCompose Clean Baseリポジトリで公開しています。日本語の元記事はQiitaでも確認できます。

Jetpack Composeを選ぶ理由

Jetpack Composeは、Androidのモダンな宣言的UI toolkitです。現在のstateに応じたUIをcomposable functionで表現するため、Viewとアプリ状態を手作業で同期するcodeを減らせます。

このサンプルでは、特に次の三点が役立っています。

  • state中心のUI: 各画面を明確なUI stateから描画できます。
  • 再利用しやすいcomponent: framework classを継承せず、小さな要素を組み合わせられます。
  • 短いfeedback loop: previewと簡潔なKotlin codeにより、画面を素早く確認できます。

Architectureの考え方

Clean Architectureは、必ず従うframeworkではなく、依存関係を整理するための考え方です。大切なのは、業務上の判断がUI、storage、networkの具体的な実装へ直接依存しないことです。

このサンプルは、Androidのarchitecture推奨事項に近い形で、次の役割に分けています。

  1. Presentation: Compose画面とViewModelがUI stateを公開し、ユーザー操作を受け取ります。
  2. Domain: 独立してテスト・再利用する価値がある処理をuse caseとして表現します。
  3. Data: repositoryが安定したinterfaceの後ろでlocalとremoteのdata sourceをまとめます。
  4. Framework: Android固有のstorage、network、platform連携を外側の境界に置きます。

この分離によりテストしやすくなり、具体的な実装も交換しやすくなります。ただし、小さなアプリで無理にすべてのlayerを分ける必要はありません。architectureは複雑さを減らすために使うべきで、手順を増やすことが目的ではありません。

画面フロー

+-----------+        +-----------+        +------------+
|  Splash   | ------>|   Login   | ------>|    Main    |
|  Screen   |        |   Flow    |        |    Flow    |
+-----------+        +-----------+        +------------+

画面イメージ

Androidスプラッシュ画面スプラッシュAndroidログイン画面ログインAndroid登録画面登録
Androidコース画面コースAndroid受講者画面受講者

リポジトリ構成

主に三つの領域で構成しています。

  • App: アプリのentry point、navigation、Compose UI、ViewModel、use case、data contract。
  • buildSrc: build設定と、このサンプルで使うdependency versionの一元管理。
  • Framework: persistence、preference、cache、共通base typeなど、Android固有の再利用可能な実装。

Presentationは、具体的なnetwork classやdatabase classではなく、domainのcontractに依存します。Repositoryがdata sourceの詳細を隠し、ViewModelが結果をimmutableなUI stateへ変換します。そのため、実際のserviceを呼んだりUIを描画したりせずに、画面の動作をテストできます。

テストと保守

特に価値が高いのは、use case、repositoryの動作、ViewModelのstate遷移を確認するテストです。Compose UI testは、重要なユーザーフローに絞ります。このバランスなら素早いfeedbackを得ながら、細かな見た目に依存する壊れやすいテストを増やさずに済みます。

機能を追加するときも、守るべき境界がある場合にだけ抽象化を増やすことを勧めます。中身をそのまま通すclassが多い五層構成より、役割が明確な二層構成のほうが良い場合もあります。

まとめ

このstarterは、state中心のUI、明確な依存関係、テスト可能な業務処理、外側に分離したframework codeという、Composeプロジェクトの保守しやすい基準を示しています。実際には、製品の規模とriskに合わせて調整してください。

質問や提案があれば、GitHubリポジトリのissue、またはLinkedInからご連絡ください。

Xで話す • GitHubで見る