5分でわかる。。。かもしれない。クリーンアーキテクチャ

目標

クリーンアーキテクチャをざっくり5分でわかるように説明することが目的。
※結構、前に読んだ本。残った記憶からなら本筋だけ纏められるかとおもってTry！

説明

クリーンアーキテクチャ聞いたことある人も聞いたことない人もまず次の図から始まる。

元ネタはThe Clean Code Blogで、書籍化されたものが有名なものがClean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

この図や本について、いろいろな説明が試みられているけど、基本的には以下のことを言っているだけと理解してOKと思っています。

• なるべく変更したくないものを中心にして、他レイヤーが中心に依存するように配置する
• 依存の流れは中心へ。だけど、制御の流れは中から外も有り

いっていることは、ほんとこれだけ以上。

中心に依存するって？

コンポーネントＡとコンポーネントＢがあったとして、Ａ->Ｂと依存しているみたいな状況では、Ｂを変更するとＡに影響する。

つまり修正しないといけないかもしれない。テストしないといけないかもしれない。
だから、「変更したくないものを依存される側においておけば変更に強い！」といえるよね！

だから、図の例ではDB->Gateway->Usecaseとすることで、DB変更したことに起因してUsecaseのコードをベタベタ修正することを防ごうとしている。

ここまでの説明で「でもUsecaseはDBを使うよね。使うっていうことは依存するじゃん！」と思う人。
作者はこれに対抗する道具は「依存関係逆転の原則」であり、これを設計に用いることで"使う"、"呼び出すといった制御の流れと依存の関係と切り離せるよ。と教えてくれている。

依存関係逆転の原則の説明は書籍かココの説明を見ると分かりやすいです。

依存関係逆転の原則を使うことで、インターフェースへの依存による依存方向の操作が実現できる。これによりコンポーネント間の依存を配置できることを利用して、変更をあまりしたくないコンポーネント、重要なコンポーネントに対して依存を向ける設計することが可能になる。

こうすると変更に強いって言える。これがいいアーキテクチャの原則じゃないかなぁ？というのがクリーンアーキテクチャで作者が言いたいことではないかと受け取っている。

思うところ

設計したものは実装していくので、最新的にはどう実装するのかという点は気になるところ。
だけど、作者も書籍中で

　 若いプログラマ は「そんなわけがない」と言うかもしれない。昔は昔、今は今。過去のルールが 今でも通用するわけがないと思うのだろう。もしそう考えているのなら、残念ながら間違っている。ルールは何も変わっていない。言語やフレームワークやパラダイムがまったく新しいものに変わったところで、ルール自体はAlan Turingが最初のマシンコードを書いた1946年と同じままだ。でも、ひとつだけ変わったことがある。かつての我々は、そのルールがどんなものかを知らなかった。 そのせいで、 何度となくルールを破ってきた。今は違う。半世紀の経験を経て、我々はようやくルールをつかんだ。 　 時代を超越した不変のルールたち。それこそが本書のすべて だ。

Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ; 角 征典; 高木 正弘. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) (Kindle の位置No.318-324). 株式会社ドワンゴ. Kindle 版. 

と話しており、原理原則の話をしたいとして語られているので読むほうもそのつもりで、自分が作ったものを俯瞰して大体初めの図のような依存関係になっていればヨシ！とするでいいと思う。

思うところ２

自己満足のため？というとそうでもなく。実体験からこの原理原則は結構大事だと思っている。

例えば、地図検索サービスをつくることを考える。
このときUI->サービス->DBと依存関係が付いており、DBチームが用意したAPIをサービス中のいたるところで触っているとする。この状態でDBが変更されるとサービスがすべてテストし直しになり、とても変更に強いとは言えない。

誰しも設計が悪いことが原因で「影響範囲が大きすぎるから変更できません」ということを言ったり、聞いたりしたことはあるのでなかろうか。

こういったことを防ぐためには"サービスのいたるところでＤＢ触るのをやめる"と思う。
これが結局、

• DBに触る箇所を集積する
• 集積してラップするクラスはサービスの持ちモノなので
  　APIをサービスが決めることになる
  　→関係上サービスが実現してほしいインターフェースをDBが実現するとなる

サービス<-DBという依存になっていく。

思うところ３

テストに強い。まじで強い。外部コンポーネントを直接触らずインターフェースが間に挟まるのでDIするのが超楽になると思う。