Android Architecture Blueprints の Clean Architecture 実装サンプルを読む

Android Architecture Blueprints には、GoogleによってMVVMやMVPなどの様々なアーキテクチャ実装や、ライブラリ利用のサンプルが公開されています。
本記事は、その中でも Clean Architecture の実装サンプルである todo-mvp-clean を読むことにより、書籍『Clean Architecture　達人に学ぶソフトウェアの構造と設計』の内容をより実践的に理解することを目的としています。

todo-mvp-cleanの位置付け

MVP実装のサンプルである todo-mvp からの変更点として、Presentation LayerとData Layerの間にDomain Layerが追加されています。Use caseがクラスとして切り出されている点が、Clean Architectureのわかりやすい特徴と言えそうです。

SOLID原則の目的のひとつは「変更に強くすること」

Clean Architectureの観点では、「データベースは詳細 」¹であり、ビジネスルールに影響を与えません。
このTODOアプリは、@969581f にて DBライブラリをSQLiteOpenHelperからRoomに変更しています。
永続化されたTODO情報へのアクセス方法は、 [TasksDataSource] (https://github.com/googlesamples/android-architecture/blob/todo-mvp-clean/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/data/source/TasksDataSource.java) インターフェースに定義されています。そして、DBの具象実装は TasksLocalDataSource となります。
SOLID原則 に乗っ取ってモジュール²が分離されているので、DBが変わってもインターフェースの変更なしで具象実装を変更していることが確認できます。

SOLID原則とは

「第三部　設計の原則」にて、５章にわたって解説されています。
SOLID原則の目的は以下の３つであるとされています。

• 変更に強いこと
• 理解しやすいこと
• コンポーネントの基盤として、多くのソフトウェアシステムで利用できること

以下の５つの原則の頭文字をとって、SOLID原則と呼ばれます。

1. クラスはたったひとつのアクターに対して責務を負うべき（Simple Responsibility Principle）

• 振る舞いの変更は、コードの修正より追加で実現 (Open-Closed Principle)
• 個々のパーツが交換可能となるような契約に従う (Liscov Substitution Principle)
• 使ってないものへの依存はインターフェース分離で回避すべき (Interface Segregation Principle)
• 上位レベルの方針実装コードが下位レベルの詳細に依存せず、逆方向に依存すべき（Dependency Inversation Principle）

Clean Architectureで実装するとはどういうことか

SOLID原則はClean Architecture固有の概念ではありませんし、TasksDataSourceはRepositoryパターンで実装されているとも言えそうです。次の記事ではUsecaseの周辺を読み解いていき、さらにClean Architectureについての理解を深めていこうと思います。

備考：公式以外のClean Architecture実装サンプル

1. android10/Android-CleanArchitecture ★1万超の有名リポジトリ。

• android10/Android-CleanArchitecture-Kotlin 1のKotlinリニューアル版。
• bufferapp/clean-architecture-components-boilerplate AACを導入したClean Architectureサンプル。

1. 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 第30章 ↩

2. Android開発の「module」ではなく、Clean Architectureにおける「モジュール」のこと。 ↩