はい、おっしゃる通りでリクエストヘッダーにCookieを載せた状態でのリクエストが求められる状況です もう少しシステム間の連携部分を詳細に説明すると、 システムA: 開発対象 システムB: 依存している外部サービス システムAに認証Cookieをリクエストヘッダーに付与してリクエスト その後システムAがリポジトリを使って集約を取得 この時リポジトリの実装では、システムAのコントローラーが受け取った認証CookieをそのままシステムBのリクエストヘッダーに付与してリクエスト（この部分が制約） となります システムAもBも /me エンドポイントに認証 Cookie を付与した状態で get リクエストを投げる必要があるイメージです

ご回答ありがとうございます 通常であればご回答のように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(); } } どのアプローチが適切でしょうか？ それともいずれも間違いでしょうか