リポジトリの戻り値と詰め替えについて教えて下さい アプリケーション層とプレゼンテーション層のやり取りにおける値の変換はアプリケーション層の責務であるとの記述がありました。 インフラ層(リポジトリ)とアプリケーション層のやり取りの際にはどこで変換を行うべきでしょうか。 なお、値の変換処理はアプリケーション層にサービスとして書いています。 ①アプリケーション層で行う場合 単純な読み取り処理の場合はインフラ層の戻り値→ドメインオブジェクト→プレゼン層用の形式、と即座に二回変換することになり違和感があります。 ②インフラ層で行う場合 アプリケーション層のサービスをインフラ層が直接呼び出していいものでしょうか。

レイヤー同士の依存関係は、オニオンアーキテクチャがよく整理できるかつシンプルなのでおすすめです。 オニオンアーキテクチャの解説はこちらご覧ください。このレイヤーの前提で話をします。 https://little-hands.hatenablog.com/entry/2018/12/10/ddd-architecture リポジトリは、インターフェイスをドメイン層において、実装クラスをインフラ層に置きます。 リポジトリに入出力するオブジェクトの的周りのことを集約と呼ぶので、リポジトリのメソッドの引数や戻り値は集約のオブジェクトです。 ドメイン層にはインターフェイスしか定義されていませんから、DBの値を取得して集約のインスタンスに詰め替えるのはインフラ層の仕事です。 集約のオブジェクトからユースケース層、プレゼンテーション層の戻り値に変換するのはそれぞれの層の責務です。ユースケースの戻り値をXxxDtoとするなら、そこに詰め替えるのはユースケース層の仕事です。 集約オブジェクトが1つならユースケースから直接返すこともあるかもしれません。 プレゼンテーション層の戻り値のオブジェクトがあるなら、そこに値を詰め替えるのはプレゼンテーション層の責務です。 一方、ユースケース層とプレゼンテーション層でそれぞれ戻り値のオブジェクトがあった場合、集約のオブジェクトから2回も詰め替えないといけないのでしょうか。これは層の責務としてはyesですが、ボイラープレート感ga 若干ありますね。その場合は手を抜くとユースケース層のオブジェクトをプレゼンテーション層でそのまま返してしまうと言う手はあります。一方、これはユースケース層の戻り値がAPIの仕様に影響すると言うことになるので、そこに直接的に影響させたくない場合は急がば回れでユースケース層とプレゼンテーション層に定義すると依存が切れます。