僕はクリーンアーキテクチャやレイヤードアーキテクチャについて真面目に学んだ訳ではないのですが、僕宛に質問という形でしたので僕が理解している範囲でお答えします。

まずクリーンアーキテクチャは「なんにでも画一的なコンポーネント分割」を適用しようとは提唱していないはずです。過去に作った何らかのソフトウェアでとあるコンポーネント分割をしたらとても良く上手く行ったのでクリーンだと呼んでいるだけで、パターンを抽出してみたので使えそうな所は使ってね、ぐらいの温度感で聞く必要があります。使いどころを間違えるとかえっておかしなコードになる事は他のデザインパターン等と同様です。

ソフトウェア開発は常に効率との戦いで、将来的に必要になる改変が過去に書いたコードの応用やパラメータ変更等で達成できた場合に高い開発効率が出せたと言えるのですが「何らかのアーキテクチャを取ったときに何らかの改変に強くなった」というのはあらゆるアーキテクチャに対して言える上に、あらゆる改変に対して強い無敵のアーキテクチャは存在しないので、つまるところ何らかのアーキテクチャが良かったというのは「この時にやった設計判断がたまたま当たった」以上の事はありません。「この株買ってたので儲かった」と過去の話をされてもこれから先も儲かるとは限らないのと同じです。株の予想で何らかの銘柄をやたら宣伝したり、過去に儲かった取引を後出しで自慢しているような物なので一層眉唾であると感じます。

レイヤードという観点で言うとRuby on Railsは天才的で、プロジェクトとして初期化した時点で走るコードの形でModel/View/Controllerが別のディレクトリに分けられてレイヤー構造が出来ています。これは「Webアプリを作りたいならこういうアーキテクチャを取れ」というのをコードのレベルから押し付けており、逆にWebアプリ以外には使えません。目的を絞れば共通部分が定義できるというのは原理的に正しく、教義自体がコードの形に具現化されている点で現場レベルでの混乱を抑えています。せっかく天才が傑作なアーキテクチャを提案してくれたのがRailsなのにそれにDDDを導入するという倒錯が世の中にあるそうで実に残念です。どちらも2004年ごろに登場した物で、Railsが優れているというのは10年以上の世の中の流れが証明したのにそこに劣った方の概念であるDDDを導入するのは、ガソリン車からエンジンとハンドルを取っ払って馬に引かせるような錯誤であると認知されて欲しいものです。

レイヤーを分ける事でコードの見通しがよくなるという思想自体には賛成ですが、DDDの人たちが言うようなドメインロジックを中心に据えてストレージをリポジトリやインフラ層に追い出したりするアイデアには反対です。疎結合を有難がる風潮が念仏のように唱えられがちですが、データはアプリケーションの本尊そのものであって、脇に置いたりあとから気軽に挿げ替えたりするものではありません。言い換えるとそこに疎結合を求めてはいけません。要件を満たすためにたまたま都合が良いからRDBMSの力を借りるのが定番になっているだけであって、本来であれば毎度ビジネス要件から逆算して大真面目に実装コストや障害への要件や実行速度などを充分吟味した果てにRDBMSを使おうという結論に至る順序で考えるべきなのです。

プログラミング一般に言えるソースコードのレイヤーの分け方という観点でいうとA Philosophy of Software Designという本が僕の思想に一番近いです。この回答の趣旨に沿った部分だけこの本に書かれている指南を僕なりに解釈して抽出するとこうなります。

• クラスやインタフェースは少なければ少ないほど認知負荷が減るし変更に強い

• 少ないインタフェースでより多くの事ができるのが良い設計。その向こうでどんな複雑な事をしても認知負荷を増やさないので。

• 再利用の予定がなくても再利用性を意識して一般化したインタフェースを定義すると直交性が高まり生産性が上がるが、時には段階をすっ飛ばす事が良いこともある

いかがでしょうか。とにかく大量のクラスを定義することを是とする風潮に対して正面から反対してくれる良い本だと感じています。