質問者さん
リポジトリの戻り値と詰め替えについて教えて下さい
アプリケーション層とプレゼンテーション層のやり取りにおける値の変換はアプリケーション層の責務であるとの記述がありました。
インフラ層(リポジトリ)とアプリケーション層のやり取りの際にはどこで変換を行うべきでしょうか。
なお、値の変換処理はアプリケーション層にサービスとして書いています。
①アプリケーション層で行う場合
単純な読み取り処理の場合はインフラ層の戻り値→ドメインオブジェクト→プレゼン層用の形式、と即座に二回変換することになり違和感があります。
②インフラ層で行う場合
アプリケーション層のサービスをインフラ層が直接呼び出していいものでしょうか。
2024年04月25日
松岡@ログラス/DDD,アジャイルさん
レイヤー同士の依存関係は、オニオンアーキテクチャがよく整理できるかつシンプルなのでおすすめです。
オニオンアーキテクチャの解説はこちらご覧ください。このレイヤーの前提で話をします。
https://little-hands.hatenablog.com/entry/2018/12/10/ddd-architecture
リポジトリは、インターフェイスをドメイン層において、実装クラスをインフラ層に置きます。
リポジトリに入出力するオブジェクトの的周りのことを集約と呼ぶので、リポジトリのメソッドの引数や戻り値は集約のオブジェクトです。
ドメイン層にはインターフェイスしか定義されていませんから、DBの値を取得して集約のインスタンスに詰め替えるのはインフラ層の仕事です。
集約のオブジェクトからユースケース層、プレゼンテーション層の戻り値に変換するのはそれぞれの層の責務です。ユースケースの戻り値をXxxDtoとするなら、そこに詰め替えるのはユースケース層の仕事です。
集約オブジェクトが1つならユースケースから直接返すこともあるかもしれません。
プレゼンテーション層の戻り値のオブジェクトがあるなら、そこに値を詰め替えるのはプレゼンテーション層の責務です。
一方、ユースケース層とプレゼンテーション層でそれぞれ戻り値のオブジェクトがあった場合、集約のオブジェクトから2回も詰め替えないといけないのでしょうか。これは層の責務としてはyesですが、ボイラープレート感ga
若干ありますね。その場合は手を抜くとユースケース層のオブジェクトをプレゼンテーション層でそのまま返してしまうと言う手はあります。一方、これはユースケース層の戻り値がAPIの仕様に影響すると言うことになるので、そこに直接的に影響させたくない場合は急がば回れでユースケース層とプレゼンテーション層に定義すると依存が切れます。
松岡@ログラス/DDD,アジャイルさんに 質問してみましょう！
松岡@ログラス/DDD,アジャイル
DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw
松岡@ログラス/DDD,アジャイルさんが
最近答えた質問
10月16日
いつもお世話になっております。DDDを実践していて以下の点が気になりましたので質問させて頂きたいです。
例えば、あるエンティティが、自分が持っている属性ごとに異なる計算（ifやswitch）をしているメソッドがあるとします。（演劇エンティティの場合：タイプがコメディの場合の料金計算処理とタイプがシリアスの場合の料金計算が条件分岐分かれているメソッドを持っている場合など）
今後の改修で演劇タイプがどんどん増えてきた場合、メソッド内の条件分岐もどんどん増えていくことになります。この場合どのようにして保守性をあげれば良いでしょうか？
ストラテジやサブクラスによる対応をした時にドメインモデルとの差が出てきてしまい、悩んでおります。ご回答いただけると幸いです
10月16日
ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか？
10月14日
ドメイン知識の実装について質問です。
ユーザー編集の可否判定に以下のルールがあります：
- 編集権限を持ったユーザーのみ編集可能
- 対象ユーザーのステータスが無効の場合は編集不可
- システム設定で編集が許可されていない場合は編集不可
これをドメイン層に実装する際、以下のクラスを考えています：
- Userクラス（氏名、ステータス等を保持）
- Contextクラス（権限、システム設定等を保持）
実装案：
案A: ドメインサービス
public class UserEditService {
public boolean canEdit(User user, Context context) {
return !user.getStatus().equals("invalid")
&& context.hasPermission("edit")
&& context.isEditAllowed();
}
}
案B: 各クラスに責任を分散
public class User {
public boolean isEditable() {
return !this.status.equals("invalid");
}
}
public class Context {
public boolean canPerformEdit() {
return this.hasPermission("edit") && this.isEditAllowed();
}
}
// 使用時
if (user.isEditable() && context.canPerformEdit()) {
// 編集処理
}
案C: 一方に他方を渡す
public class User {
public boolean canBeEditedBy(Context context) {
return !this.status.equals("invalid")
&& context.hasPermission("edit")
&& context.isEditAllowed();
}
}
どのアプローチが適切でしょうか？ それともいずれも間違いでしょうか