一度は目にするクリーンアーキテクチャですが、細かなディレクトリの話ではなく超大枠だけ喩えを用いてまとめてみました
あくまで僕の理解なので間違いがあれば指摘いただきたいです！
クリーンアーキテクチャとはズバリ
よく目にするのが
この図であるが、
「役割ごとにきっちり部屋を分けて、お互いが変に干渉しないようにしよう！」 というソフトウェアの設計思想。基本的に内側になればなるほど大事。
一番大事なのが内側の円は外側の円について何も知ってはいけないということ
つまり
青の部分は緑の部分を知っててもいいけど、緑の部分が青の部分を知っててはいけない。
なるほどよくわからんので「料理」で例えてみる
1.Entitiesの部分
→根幹的なレシピ。「カレーには野菜と肉を入れる」といった、料理で一番大事な部分
この時「カレーのレシピ」は誰がどんな器具で作るなどに左右されない（キャンプ場でも高級レストランでも作れる）
2.use casesの部分
→シェフが「何をするのか」を決める部分。野菜を切る、肉を炒めるなど、、
3.Controllersの部分
→usecases層で指示された内容をframeworks層に伝えるための翻訳係。シェフが温めて！といったものを「コンロをつける」という動作に変換する部分
4.Frameworksの部分
→実際に揃える器具たちの細かな情報。「職人の作った〇〇包丁」「A社の最新のコンロ」などといった感じ
このように各層で責務を分けるのがクリーンアーキテクチャ。例えばもし、第二層が第四層を知ってしまっている場合、シェフは「A社の最新のコンロがないとカレーが作れない」という状態になってしまう。（そんなことはない
知らない状態であれば、たとえいくらFrameworks層のコンロや包丁を買い換えたりアップデートしたりしても、その内側の層には一切影響が及ばない。（干渉してないから
また、各段階において責務が独立しているのでテストがとてもしやすい。
まとめ
なんとなくよくみる図については理解ができました。とにかく、責務を独立させ、長期的に運用・メンテナンスするためにかなり向いてるアーキテクチャなんだなという感想です。
実際に今度は自分でコードに落とし込んでみたいです