ソフトウェア アーキテクチャは、ソフトウェアを作成するための一連のルールを定義します。これは、開発者がソフトウェアの信頼性とスケーラビリティを確保するために適切な方法でコードを構造化するのに役立ちます。

スケーラビリティ、パフォーマンス、セキュリティ、コード削減などのさまざまな品質を判断し、設計リスクを分析して軽減するのに役立ちます。ソフトウェア アーキテクチャは、設計および実装チームの青写真として機能します。

最も一般的に知られているソフトウェア アーキテクチャは次のとおりです。

• MVC (モデル-ビュー-コントローラー)
• MVP (モデル-ビュー-プレゼンター)
• MVVM (モデル-ビュー-ビュー-モデル)

ピンポイント: MVVM パターンは最初は適切ですが、コードの複雑さが増すにつれて、コード ベースの要件に従って複雑さを処理するためのより強力なアーキテクチャが必要になります。

そこで登場するのがクリーン アーキテクチャです。

クリーンなアーキテクチャ

建築とは、何を書くべきかではなく、何を書いてはいけないかを知ることです。

—クリーン・アーキテクチャー by アンクル・ボブ

クリーン アーキテクチャは基本的に関心事の分離に重点を置いています。クリーン アーキテクチャに従っている場合、指定されたレイヤー数はありません。レイヤーは必要なだけ追加できます。経験則として、内側の層は外側の層を参照すべきではなく、中心に向かうにつれて詳細が抽象的になるはずです。

上の図では、外側の層は詳細な実装で構成され、内側の層は抽象化に焦点を当てています。このアプローチにより、ソフトウェア開発中に使用する実際のツールの下位レベルの依存関係からビジネス層が分離されます。

ソフトウェアは、開発ツール (使用するハードウェアとデータベースの種類) を変更したときに、ビジネス ロジックを定義するコードに影響を与えないようにする必要があります。Clean Architecture は、この一般的な考え方に基づいて動作します。

Clean Architecture レイヤーは、中心に向かうにつれてフェードインする球体として想像できます。同センターは、特定のタスクがどのように処理されるかについて具体的な詳細を明らかにしていない。ソフトウェアが従うべきルール/ポリシーを定義するだけです (これがソフトウェアのビジネス ロジックです)。

『Clean Architecture』の本の以下のコメントは、この点全体をうまく要約しています。

クリーン アーチでは、高レベルのビジネス ロジック/ポリシーを含むモジュールは、低レベルのモジュールから独立している必要があります。

依存関係のルール

レイヤーは、その上のレイヤー内の何も参照してはなりません。外側の層は、内側の層に含まれる高次のアイデアに依存する必要があります。

実在物

エンティティは、クラス、オブジェクト、データ構造、またはそれらの組み合わせによって記述できるビジネス ルールです。外側のレベルの詳細 (操作フローなど) に変更がある場合、これらが変更される可能性は最も低いです。

使用例

ユースケースには、アプリケーション固有のビジネス ルールが含まれています。これらのルールは、エンティティ層のビジネス ルールをアプリケーション固有の運用ルールに変換するのに役立ちます。

インターフェースアダプター

この層は、ユースケースからのデータを、GUI フレームワークや Web UI などのフレームワーク層で使用できるように変換します。

フレームワークとドライバー

一般に、この層は使用されるフレームワークとデータベースの最も外側の詳細な実装であるため、この層にコードを記述する必要はありません。
この層のほとんどには、内部層からのコードを結合するコードが含まれており、データを取得して表現のために変換する方法を定義します。

Clean Architecture を使用するたびに、これらのレイヤーを指定された名前で使用する必要はありません。別の名前を付けることもできますが、依存関係ルールは常に当てはまります。

クリーンアーキテクチャの利点

• 制度変更が容易になります。
• ビジネス ロジックはコード ベースの他の層から完全に分離されており、他の層はビジネス ルールに依存するため、システムの機能の追加/更新が簡単になります。
• コードは分離されているため、すべてのレイヤーをブラック ボックスとして扱うことができ、コードのテストに役立ちます。
• すべてのモジュールは、詳細ではなくその目的を定義します。これは、技術的な詳細を深く調べるのではなく、アプリが何を行うのかを理解するのに役立ちます。

• これは単純なプロジェクトには望ましい選択ではありません。プロジェクトが複雑でない場合は、不必要にファイルを作成し、MVC や単純な MVVM などの単純なアーキテクチャで実現できるコードを作成します。
• 学習曲線は急勾配です。
• このアーキテクチャで各層がどのように機能するかを明確に理解していないと、責任を適切な層に分割する方法を理解するのは面倒になる可能性があります。

Android プラットフォーム上でクリーンなアーキテクチャを備えた最もシンプルな TODO アプリを作成しました。完全なコードはGitHubで見つけることができます。

Clean Architecture を使用して TODO アプリのような単純なものを作成することは、アーキテクチャのすべての側面をカバーしているわけではないことに注意してください。

基本的な実装を理解し、より複雑な機能に取り組んでいくという考え方です。

このアプローチで使用される階層構造は次のとおりです。

同じ階層化がディレクトリ構造にも反映されます。

階層化は実装によって異なる場合があります。ただし、コード ベースの構造化では、誰 (レイヤーと要素) が誰に依存するかに重点を置く必要があります。

コード構造の複雑さと差別化に応じてレイヤーを追加できます。クリーン アーキテクチャにいくつのレイヤーを含めるべきかについて、厳密な規則はありません。

ここでは、コア モジュールを実際のアプリへの依存関係として含めています。コアは内部レイヤー (ドメイン、データ、ユースケース) として機能し、Android アプリは実装の最外部レイヤー (フレームワークとプレゼンテーション) として機能します。

ドメイン

ドメイン層は、アプリケーション/モジュールの概念を記述するコア エンティティで構成されます。これらのエンティティは外層から独立しており、外層からの内容 (データ、ユースケースなど) について決して言及すべきではありません。

ここでは、基本的なタスクとそのプロパティを定義するエンティティとしてTaskがあります。

データ

この層はデータとの対話を定義します。データに対する操作を定義するTaskDataSourceがあります。次に、複数のデータ ソースを 1 つのリポジトリに結合し、そのリポジトリを使用してデータにアクセスするためのTaskRepositoryを定義しました。

ここでは、データ ソースは 1 つだけです。基本的に、 TaskDataSource メソッドとTaskRepositoryメソッドへの 1 対 1 のマッピングですが、一見すると冗長に見えます。ただし、アプリケーションが拡張され、複数の場所からデータ ソースがある場合、つまりインターネット、ローカル データベース、またはユーザー ファイルに保存されているデータからデータをダウンロードする場合、リポジトリ パターンは便利です。

TaskRepositoryは、以下で説明するユースケースで使用されます。

使用事例

この層は、データに対して実行できる操作を定義し、データに基づいたユースケースを形成します。プレゼンテーション層は、これらのユースケースを直接使用して、データを表示または操作します。

データに対してさまざまな操作を実行するために定義されたユースケースを以下に示します。

フレームワーク

この層は、データ層で定義されたデータ ソースを実装し、プラットフォーム固有の実装を提供します。

実装では、TaskDataSourceImpl経由でRoomデータベースを使用して TaskDataSourceを実装しました。

プレゼンテーション

この層は、コード内のプレゼンテーション ロジックと、ユーザーにデータを表示するためにプラットフォーム固有のビューがどのように使用されるかを定義します。ここには、ユース ケース レイヤーで定義されたユース ケースを呼び出し、Android ビューを使用してそれらを表示するビュー モデルがあります。

以上です！

まとめ

クリーン アーキテクチャと、それを Android 開発に実装する方法が明確になることを願っています。

サンプル TODO アプリの完全なコードはGitHubで見つけることができます。コード構造について提案がある場合は、PR を上げてください。奮って投稿をお願いいたします。

コーディングを楽しんでください!

PS指導してくれたPrem PatelとサポートしてくれたSanat Shuklaに特別に感謝します。

使用した参考文献

クリーンアーキテクチャの歴史