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

なるほど。だとすると ①まず外部サービスを呼び出すものはリポジトリではなくXxxServiceClientといった形のインターフェイスをドメイン層に定義するのが良いと思います。リポジトリは集約単位で基本的にはデータベースからデータを出し入れするものになりますが、実際のところはトランザクションを意識する必要がある場合が多いと思います。その際、トランザクションが効く内部の処理と、トランザクションが効かない外部の処理をリポジトリという同じ見せ方にしてしまうと、ロールバックが必要な際に部分的にロールバックが効かないといった事故のリスクになります。また、今回問題の違和感の通り、渡すべき値の性質が異なるものになるので、リポジトリとは別の種類のインターフェイスとして定義した方がよいと思います。 一般的に技術的な裏側は隠蔽したくなりますが、それはインターフェイスを利用する側が隠蔽されている内容について関心を持たなくて良い場合です。トランザクションやCookieを渡すなど利用元が意識せざるを得ないものがある場合は、それを隠蔽しない方が良いと思います。 ②Cookieの値はそのサービス呼び出しのためのパラメーター型をドメイン層に定義しましょう。 リクエストのCookie型を呼び出しパラメータークラスに詰め替え、XxxServiceインフラ層の実装クラスの中で改めてCookieに詰め替えてリクエストします。 なお、XxxServiceClientにどの抽象度で名前をつけるかはこれもまた呼び出し元がどこまで意識すべきかによって変わります。 例えば支払いの外部サービスに通信する場合、ですが「支払いをするサービス」という意識だけでよければPaymentServiceClientとなり、画面から支払いサービスを選択するなど明確な意識があるなどの場合はStripeClientなどと具体的な名前にしてもよいでしょう。