以下の2点に迷ったので、結論とそれに至るまでの考えを書き残しています。requestオブジェクトはどのレイヤーまで持ち回すべきか?responseオブジェクトはどのレイヤーで生成するべきか?背景よくあるシンプルなCRUDアプリを実装する際、以下のような処理を実装するとします。repositoryのような依存関係で実装する必要があります。※詳しくは後述するCleanArchtectureのドーナツ絵を参考にしてください。そこで、上記依存関係に則ってコード書いている時にふとこんなことを思いました。「responseオブジェクトは本来どこで生成すべきか?」Golangのコードで言うと以下のような実装です。}}一見するとMVCなどでよく見る割と当たり前な実装です。両コードの依存性も依存性の逆転の原則に則っており、CleanArchtectureの依存ルールにも反さないようにしています。repository)が依存するようになっています。request/responseはpresenterパッケージに属しているのでこちらもInterfaceレイヤーのコードとなります。usecaseという依存関係になってしまっています。これではCleanArchtectureの依存ルールに反してしまいます。するべきか?この違和感に気づいた際に考えたのは以下の2つの解決策でした。usecaseパッケージにrequest/responseのinterfaceを用意し、抽象に依存させることで依存関係を逆転させる。そもそもusecaseパッケージでrequest/responseパッケージの資源を操作しない。結論からいうとボツ案です。理由は簡単でrequest/responseはDTOであるため、あらゆるパッケージに依存しない疎結合な資源でなくてはならないからです。そのため依存関係の逆転を実現するためにusecase側にinterfaceを置くと、外部のパッケージに依存する密結合な資源となってしまいます。そもそも構造体は振る舞いやデータに着目するものであって、抽象化するべきものではない。(こんな論理たてなくとも普通に考えてreq/resにinterfaceがある時点で怪しいコードですが。)usecaseパッケージでrequest/responseパッケージの資源を操作しない。実現方法は簡単で、提題の通りにusecaseは操作に必要なもののみを受け取り、操作した結果のみを返す形式に下だけです。&result}requestの分解とresponseの生成をcontrollerで行っています。依存関係的にも問題がありません。このusecaseのテストコードという観点でも、テストコードの依存がrequest/responseに波及することがないため、依存関係をテスト対象のみに留めることができたり、controllerパッケージ側の都合でrequest/responseが変更されたりしても、usecase及びusecaseのテストコードに影響が出るということもありません。引数が多い場合は、さらにusecase側にDTOを作成しそのDTOにrequestの値を詰め直すのが理想でしょう。まとめまとめるとrequestオブジェクトはApplicationレイヤーまで持ち回すべきではないresponseオブジェクトはApplicationレイヤーで生成するべきではないとなり、reqest/responseオブジェクトはInterfaceレイヤーで分解/生成を行うとなりました。今までcontrollerやusecase、他には今回取り上げていませんがentitesやbusinessruleなどの依存関係には気を払っていましたが、reqest/responseはMVCの頃と同じようになにも疑わずに扱っていました。controllerにバリデーション以外の処理を書くのもMVCになれてると違和感ですが、ここまでの論理の積み上げでは正しいと思うので、これがあるべきとして納得しようと思ってますw(理想はcontrollerにたどり着いた際にバリデーションとリフレクションをこなしてくれる横断処理があるといいでしょう)終わりにここまで読んでくださりありがとうございました。1からCleanArchtectureに挑戦しようとしている方や、お仕事で使う(使ってる)という方の参考になると幸いです。有識者の方で意見等ありましたら遠慮なく言ってくださると嬉しいです。最後に♡やバッジ、拡散(ついでにお賽銭)いただけると筆者の励みになりますので、心や財布に余裕がある方はよろしくおねがいします!iwaseshi救いのヒーローをリスペクトしているエンジニア。Discussioniwaseshi救いのヒーローをリスペクトしているエンジニア。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。