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の観点では、「データベースは詳細 」1であり、ビジネスルールに影響を与えません。
このTODOアプリは、@969581f にて DBライブラリをSQLiteOpenHelperからRoomに変更しています。
永続化されたTODO情報へのアクセス方法は、 TasksDataSource インターフェースに定義されています。そして、DBの具象実装は TasksLocalDataSource となります。
SOLID原則 に乗っ取ってモジュール2が分離されているので、DBが変わってもインターフェースの変更なしで具象実装を変更していることが確認できます。
SOLID原則とは
「第三部 設計の原則」にて、５章にわたって解説されています。
SOLID原則の目的は以下の３つであるとされています。
- 変更に強いこと
- 理解しやすいこと
- コンポーネントの基盤として、多くのソフトウェアシステムで利用できること
以下の５つの原則の頭文字をとって、SOLID原則と呼ばれます。
- クラスはたったひとつのアクターに対して責務を負うべき（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実装サンプル
- android10/Android-CleanArchitecture ★1万超の有名リポジトリ。
- android10/Android-CleanArchitecture-Kotlin 1のKotlinリニューアル版。
- bufferapp/clean-architecture-components-boilerplate AACを導入したClean Architectureサンプル。