この記事で伝えたいこと
Now in Androidのドキュメントを読んでいて、興味深い議論を見つけたので、自分なりの解釈を加えつつピックアップしていこうと思います。
アーキテクチャの解説を含みますが、私の個人的な解釈や大雑把な説明に留める箇所が多々あるので、正確な情報でない部分がありましたらご指摘ください。
また、今回は議論の一部のみを取り上げます。詳細な内容は、後述するリンク先のページでご確認ください。
はじめに
最近アーキテクチャについて勉強していましたが、なかなか頭に入ってきませんでした。Clean Architectureについても理解が浅く、Google推奨アーキテクチャとの違いもなんだかよくわかっていませんでした。
どうしたらアーキテクチャの全体像を掴めるんだろうと思い、まずはAndroidエンジニアには馴染み深いNow in Androidを参考にしてみることにしました。
アーキテクチャの解説ドキュメントを読もうとしたところ、冒頭に興味深い注意書きが…
The official Android architecture is different from other architectures, such as "Clean Architecture". Concepts from other architectures may not apply here, or be applied in different ways. More discussion here.
翻訳すると、
公式のAndroidアーキテクチャは、「クリーン・アーキテクチャ」のような他のアーキテクチャとは異なります。他のアーキテクチャのコンセプトは、ここでは適用されないかもしれないし、異なる方法で適用されるかもしれない。詳しくはこちらをご覧ください。
なんと！今の自分にぴったりのトピックじゃないかと思い、確認してみました。
そして議論内容を追ってみて、なんとなく同じようなアーキテクチャだと思っていた両者の違いを知りました。どんな違いがあるのか、議論の内容を一部ピックアップしていこうと思います。
SOLID原則とClean Architectureに違反しているという問題提起
まず該当のissueがこちらです。
このissueでは、主に以下のような内容を指摘しています。
- ドメイン層がデータ層に依存しており、Clean Architectureの原則に違反している
- ドメイン層はビジネスロジックの純粋な部分なので、データ層に依存することはないはず
この問題提起から、Now in AndroidでなぜClean Architectureを使用しないのか、Google推奨アーキテクチャとClean Architectureの違いなどについて議論が広がっていきます。
Now in AndroidではなぜClean Architectureを使用しないのか
Googleのエンジニアが以下のように回答しています。
Many apps aren't complex enough to justify having a domain layer. This is why in the official guidance the domain layer is optional. You can build your app with the UI layer dependent on the data layer, then introduce the domain layer later if the need arises. Ultimately we feel that the official guidance offers the best approach for most Android apps.
It's worth saying that the official guidance is just that: guidance. It's not intended to be a one-size fits all. Developers should question whether the ui->(optional domain)->data approach is right for their app's requirements.
翻訳すると、
多くのアプリは、ドメインレイヤーを持つことを正当化できるほど複雑ではない。そのため、公式ガイダンスではドメインレイヤーはオプションとなっている。UIレイヤーをデータレイヤーに依存させてアプリを構築し、必要に応じてドメインレイヤーを後から導入することができます。最終的には、公式ガイダンスがほとんどのAndroidアプリに最適なアプローチを提供していると感じています。
公式ガイダンスは、あくまでもガイダンスであることをお伝えしておきます。このガイダンスはあくまでもガイダンスであり、万能を意図したものではありません。開発者は、ui->(オプションのドメイン)->dataのアプローチが自分のアプリの要件に合っているかどうかを疑うべきです。
なるほど、たしかに必要に応じてドメインレイヤーを導入することで、柔軟にアプリのアーキテクチャを拡張できそうです。アーキテクチャはオーバーエンジニアリングになりがちだと感じるので、この考え方は理に適ってるように見えます。
Google推奨アーキテクチャとClean Architectureは違うの？
上記のissueに対して、「Clean ArchitectureとGoogle推奨アーキテクチャの図を比べてみて、同じように見える。なにか見落としはありますか？」といったコメントが追加されました。
私も似たような構造に見えていたので、これはありがちな勘違いなのかもしれないです。
UI Layer(Google推奨アーキテクチャ)→UI・Presenters(Clean Architecture)
Domain Layer(Google推奨アーキテクチャ)→Use Cases(Clean Architecture)
Data Layer(Google推奨アーキテクチャ)→Entities(Clean Architecture)
と見立てることで、同じ考え方として扱うことができるのではないだろうか？という質問です。
Google推奨アーキテクチャとClean Architectureの違い
上記の質問に対して、こちらもGoogleのエンジニアが以下のように返信をしています。
You're right, they are similar, but not identical. The differences are highlighted in red below:
翻訳すると、
似ていますが、同じではありません。違いが赤で強調表示されています。
主に2つの違いがあります。
1つ目は、依存の方向の違いです。Google推奨アーキテクチャではUI→Domain→Dataと依存関係の方向が示されているのに対して、Clean ArchitectureではUIもDataもDomainに依存しています。
もう一つは、DomainがOptionalである点です。Clean Architectureではアプリケーションフレームワークに依存しないビジネスルールを中心に起きますが、「Now in AndroidではなぜClean Architectureを使用しないのか」でも説明している通り、Google推奨アーキテクチャでは複雑なビジネスロジックがない場合は省略することもあります。
なるほど、見かけ上は同じように見えるのも納得がいきました。
ただし、厳密にはGoogle推奨アーキテクチャにおけるドメインと、Clean Architectureにおけるドメインは違う概念です。そちらに関しては、issueのスレッドで議論の続きをご確認ください。
まとめ
Google推奨アーキテクチャとClean Architectureの違いについて、Googleのエンジニアの見解や議論の内容を追うことで理解を深めることができました。
私が個人開発しているアプリではGoogle推奨アーキテクチャをベースにしていますが、Clean Architectureの考え方を取り入れて、一度リファクタリングをしてみようかなと思います。