参考
マーティン.C.ロバーツさんのブログをもとに、学んだことをまとめます。
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
クリーンアーキテクチャとは
クリーンアーキテクチャは、関心の分離を実現し、依存関係のコントロールをするためのアーキテクチャ。
アプリケーションの構造をレイヤーに分けて、役割の違うソースを一緒にしないことで管理しやすくする考え方。
円(ブログ参照)の内側へ進むほど、重要度が上がっていく。
そのため、依存関係も常に外側から内側へと向かう。
内側の層が外側の層に依存してはいけない。
1.Frameworks and Drivers
webとか、DBとか、アプリケーションの外部に当たる部分の実装。
（フレームワークがここ、というのはちょっと違和感があるけど、フレームワークがあまりアーキテクチャに対応していなかった時代なのかもしれない）
2.Interface Adapters
外側のレイヤーと内側のレイヤーの通信を行う部分。
外側のレイヤーからデータを受け取って、より内部のレイヤーにとって便利な形に整形して渡す、あるいは、内部のレイヤーからデータを受け取って、外部のレイヤーに渡す。
データの変換、ビジネスロジックの呼び出しを行うレイヤー。
3.Use Cases
アプリケーション特有のビジネスロジックを記載する。
よく混同しがちだが、ここには対象業務のビジネスロジックは記載しない。
アプリケーションがなければ存在しないようなビジネスロジックを記載する。
アプリケーションに依存しないビジネスロジックは、もっと内側のレイヤーになる。
4.Entity
業務特有のビジネスロジックを記載する。
あるいは、業務のない、シンプルなアプリケーションの場合は、アプリケーションのビジネスロジックを書く場所にもなる。
4つ以外にレイヤーを持ってもいいが、依存関係は常に外から内にすること。
まとめ
一番大事なのは、業務特有のビジネスロジックと、アプリケーション特有のビジネスロジックを分けること、そして、重要な部分が、より重要でない部分に依存しないようにすること。
入力値の整形をどこでするかとか、バリデーションをどこでするか、みたいなことは必要に応じてされていればどこでしてもいいと思う。