ご回答ありがとうございます Twitterの方でも他の方が被せてくださった説明も合わせて拝見しました 「Cookieは技術的関心ごとだからインフラ層に閉じ込める」という考えに固執しすぎていたこと、またリポジトリに対する理解も深まり、具体的な実装イメージも付き非常に助かりました 追加の質問ではないですがこの場を借りてお礼を申し上げます

ご回答ありがとうございます 通常であればご回答のようにCookieからUserIdに詰め替えてリポジトリを呼び出すことについては理解しているのですが、本件の質問内容としては、リポジトリで呼び出される外部システムのAPIの制約として、「UserIdを使わずにCookieをリクエストに乗せること」が制約条件にある場合、どのような手段が取れるか、といった趣旨となります

いつもお世話になっております。DDDを実践していて以下の点が気になりましたので質問させて頂きたいです。 例えば、あるエンティティが、自分が持っている属性ごとに異なる計算（ifやswitch）をしているメソッドがあるとします。（演劇エンティティの場合：タイプがコメディの場合の料金計算処理とタイプがシリアスの場合の料金計算が条件分岐分かれているメソッドを持っている場合など） 今後の改修で演劇タイプがどんどん増えてきた場合、メソッド内の条件分岐もどんどん増えていくことになります。この場合どのようにして保守性をあげれば良いでしょうか？ ストラテジやサブクラスによる対応をした時にドメインモデルとの差が出てきてしまい、悩んでおります。ご回答いただけると幸いです

ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか？

ドメイン知識の実装について質問です。 ユーザー編集の可否判定に以下のルールがあります： - 編集権限を持ったユーザーのみ編集可能 - 対象ユーザーのステータスが無効の場合は編集不可 - システム設定で編集が許可されていない場合は編集不可 これをドメイン層に実装する際、以下のクラスを考えています： - 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(); } } どのアプローチが適切でしょうか？ それともいずれも間違いでしょうか