クリーンアーキテクチャについて再入門したい

最近アプリケーションアーキテクチャについて考える機会が増えてきたので
備忘録的に知識整理＆改めて向き合おう、と。
（以下はあくまで私個人の解釈です）

よくあるこの図はあくまで概念にすぎない。

よく「これがクリーンアーキテクチャだ！」となりがちだが、提案者としてはそんなことは意図していない感じ。
ただ現状では、以下の図通り、いわゆる教科書通りにアプリケーションが構築されるケースがほとんど。

しかし、クリーンアーキテクチャの本質は「関心の分離」
ディレクトリ構成だったり命名だったりはどうでもよく、関心の分離ができているものはクリーンアーキテクチャと呼んでもよい（なぜなら概念だから）、と解釈できそう。

モデル駆動設計は、分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデルを探し出す。

前者がいわゆる「要件定義・ビジネスルールの明確化」的なところ、後者が「何かしらの言語を使って設計・実装」的なところかな。

設計が、あるいは設計の中心となる部分が、ドメインモデルに紐づいていないならば、そのモデルにほとんど価値はなく、ソフトウェアが正確であるかどうかも疑わしい。同じように、モデルと設計された機能との紐づけが複雑だと理解するのが難しく、実際には、設計が変更された時に紐づけを維持できなくなる。分析と設計の間に致命的な亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがないのだ。

ソフトウェアを運用していく中、あるいは開発中にこの二者がどんどん乖離していくケースが発生し、
結果としてバグが生まれたり継ぎ足し継ぎ足しの悲惨な状況が生まれたり。

なぜ乖離するのか。いわゆる分析モデルでは考慮の必要がない設計側だけの事情（永続化が必要など） を汲み取る必要が出てくるから、といった感じか。あるいはそれぞれの活動（分析モデル・設計）が不十分・分析モデルから設計への落とし込みが不十分といった感じか。

これを解決するために「両方の目的に使える単一のモデル」を探すアプローチが提案される。
いわゆる、DDD。

DDDを実現するためのアーキテクチャとして、
レイヤードアーキテクチャやオニオンアーキテクチャ、ヘキサゴナルアーキテクチャなどが提案されてきた。

クリーンアーキテクチャは、これらをひとつの概念に落とし込んだもの。

これらのアーキテクチャはどれも細部は異なるけれども、とてもよく似ている。これらはいずれも同じ目的を持っている。関心の分離だ。これらはいずれも、ソフトウェアをレイヤーに分けることによって、関心の分離を達成する。

つまり「目指すところは同じだしひとつの考え方としてまとめようぜ」的な感じか。

”関心の分離”による恩恵：

• 技術独立
  フレームワークやライブラリ、データベースはアーキテクチャに依存しない。
  これは、これらを道具として使うことを可能にし制約に嵌められないようにする。
• テスト可能
  外部要素（データベース・UI・外部APIなど）を必要とせずにテストができる。
• UI独立
  UIのみ変更できる。システムの残りの部分の変更が不要。
• 外部機能独立
  ビジネスルールは外側について何も知らない。

”関心の分離”実現のために重要なのが、依存性のルール。

このアーキテクチャを機能させる重要なルールが、依存ルールだ。このルールにおいては、ソースコードは、内側に向かってのみ依存することができる。内側の円は、外側の円についてなにも知ることはない。とくに、外側の円で宣言されたものの名前を、内側の円から言及してはならない。これは、関数、クラス、変数、あるいはその他、名前が付けられたソフトウェアのエンティティすべてに言える。

そこで出てくるのがこの図。再掲