はじめに
これは、アーキテクチャや技術要素に対して個人的な思想を示す記事です。
技術的な問題の解決策を提示するものではありませんので予めご了承ください。
また、記事内容に誤り等がございましたら、お手数ですがコメントにてご指摘いただけると幸いです。
背景
結構前にEric Evans先生のDDD本を読んだけど、全く身についた気がしない。
その後、クリーンアーキテクチャの図を見て、わりとピンときた気がした。
クリーンアーキテクチャとDDDは似たような考え方であるらしく、趣味で作っているアプリやなんやで、これを活かしていきたいと思ったので試しに何かを作る。（何を作るかは決めてない。）
本記事では、（何をつくるかも決めてないけど）アプリの設計に入る前に、
クリーンアーキテクチャのポイントについて考える。
クリーンアーキテクチャのポイント
The Clean Architecture - Link
これが上記のピンときた図（をトレースしたもの）。
矢印は依存の関係性を示しており、内部の層は外部の層を知らない。
図自体の説明をしている人は他に沢山いると思うので割愛。
インフラ層は外に置くもの
僕が「なるほど」と思ったのが、DBが矢印の始点になっているところ。
今まで面倒くさいと思っていた部分の１つが、アプリとDBが密に結合していることだったので、これである程度解決することができるのかと納得できた。
また、思想としてインフラ（手段）がドメイン（目的）に依存している形が美しいと思う。
| アーキテクチャ | 1層 | 2層 | 3層 | 4層 | 4→1層参照 |
|---|---|---|---|---|---|
| ﾚｲﾔ化ｱｰｷﾃｸﾁｬ | ｲﾝﾌﾗｽﾄﾗｸﾁｬ | ﾕｰｻﾞｲﾝﾀﾌｪｰｽ | ｱﾌﾟﾘｹｰｼｮﾝ | ドメイン | 可能 |
| ｸﾘｰﾝｱｰｷﾃｸﾁｬ | Framework&Drivers | Interface Adapters | Application Business Rules | Enterprise Business Rules | 不可 |
| ﾍｷｻｺﾞﾅﾙｱｰｷﾃｸﾁｬ | 任意(特に定義されていない) | Port&Adapter | Application | Application | 不可 |
| ｵﾆｵﾝｱｰｷﾃｸﾁｬ | Infrastructure/UserInterface/Tests | Application Services | Domain Services | Domain Model | 不可 |
レイヤ化アーキテクチャでは、インフラ層の参照はどこからでも可能であるので、この考え方よりクリーンアーキテクチャの方が制約が厳しくなっている。
この考え方は、ヘキサゴナルアーキテクチャやオニオンアーキテクチャでも同じような感じらしい。
制御の流れを単一にすること
Fluxアーキテクチャでも言われているみたいだが、クリーンアーキテクチャでも単方向の制御について言及されている。
クリーンアーキテクチャでは、必ず以下の流れで制御しなければならない。
コントローラー -> ユースケース -> プレゼンター
これをAndroidで考えたとき、ActivityやViewなんかからコントローラを呼び出すことになると解釈した。
この概念を自分なりに考えてクラス図・シーケンス図に落としてみた。
あえて図上には表現していないが、これを実現するためにはフレームワークによるDIP（ 依存関係逆転の原則）の適用が必要になる。
最も重要なのが、ユースケースオブジェクトへのOutputPortおよびRepositoryインターフェースのインジェクション機能だと思われる。
まずは、これを解決するためのフレームワークを考えることにする。
今回はここまでとして、次回は適用するフレームワークについて考えたい。
参考
・エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
・The Clean Architecture
・クリーンアーキテクチャ(The Clean Architecture翻訳)
・Hexagonal Architecture
・ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
・The Onion Architecture
・Flux