最初に
この内容は日記で技術文書ではありません。 技術知識に関して間違っている部分があるかもしれないので信用しないでください（予防線）。
当方の状況
書籍のClean Architectureを以前に読みましたが、色々な本やWebの知識と混ざりあった結果、単体でどんな内容だったかはうろ覚えです。
Clean Architectureの認識
ヘキサゴナルアーキテクチャ・オニオンアーキテクチャを参考にしつつ、SOLID原則を活かしてオリジナリティのある整理をして、かっこいい名前をつけたもの。
日本のWeb開発現場では（海外の事情を知らないの意）DDDとセットで語られることが多い印象を持っています。
Clean Architectureのよいと感じる点
この記事で一番言いたいところはここです。
自分はClean Architecture全般の知識は「知っていれば役に立つ知識」だと思っています。
Clean Architectureがアーキテクチャ設計でそのまま役に立つとは限りませんが、自分はClean Architectureの知識がソフトウェア設計に役立っていると感じています。特に保守性の理解に役立ちました。
あとは保守性を説明する際の材料にしやすいです。SOLID原則を理解するきっかけになります。
名前がキャッチーなところもいいです。業務でキャッチーな名前やフレーズをつけると言葉が一人歩きしますが、この観点も知ることができます。
Clean Architectureの難しいと感じる点
業務開発で採用して実際に保守性を上げること。
誰か教えてほしい
自分は開発現場を多く知らないので世の中の開発事情について詳しくありません。
そのため、成功したClean Architectureも成功したDDDも見かけたことがありません...。
どなたかWebで見られる成功事例・コードがあれば教えてほしいです。
Clean Architectureで気になること
抽象度
中心のEntityよりUseCaseの方が抽象度が高い...?
たとえば自分がレシピ検索サイト開発で「レシピを検索する」ユースケースをつくるなら、
UseCase：「レシピを検索する」というモデル Entity：「レシピ」のモデル
とします。この場合「レシピを検索する」ユースケースがドメインの抽象度の頂点になりませんか。
「抽象→具体」が「ドメイン（ビジネスロジック）→システム」のように変化するなら、あの同心円そのままで表現すると次のように見えます。
フレームワーク・アダプター（最もシステム寄り） ↓ インタフェースアダプター（2番目にシステム寄り） ↓ ユースケース（最もドメイン寄り） ↓ エンティティ（2番目にドメイン寄り）
この順番のズレがちょっと気になります。別に困っているわけではありませんが。ただの喉魚骨刺です。
構成が豪勢
昨今のマイクロサービス事情（最近では生成AI事情）からシステムを小さく小さく作ることが増えている認識です。 モジュラモノリスもモジュールに分けて小さく作るイメージです、が採用したことないのでここは正直よくわかっていません。
Clean Architectureの特性によって保守性を担保すると豪勢な構造になります（ここだいぶ表現が難しい）。 そして経験則では最初から一貫性を保って開発しないと持続しづらく、だからと言って小さなシステムの時点で豪勢に作り込むのもな...というジレンマに苛まれがちです。
ただ最近は生成AIによる大量コーディングができるので、豪勢でも負担は少ないんじゃないかと思ったりしています。
認識ずれがち
開発者のClean Architecture(およびDDD)に対する理解や認識がずれやすいと感じています。 私とあなたもきっとずれており、SNSでもそのあたり話題や論争になりがちです。
ドキュメントや言葉で伝えるのも難しく、こういうコードで書いてって見せるのが手っ取り早い印象です。それ以外の方法が思いついていません。
他のアーキテクチャがこれらを全て解決しているかはわからないので、話題としては不公平かもしれません。
論争を見て落ち込みがち
よーしと意気揚々とClean Architectureを知り、学び、SNSを見て、Clean Architectureディスを見て、落ち込みます。ううっ。
まとめ
SNSでは優しい言葉を使います。
