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

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

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

データ量がかなり膨大、かつ正規化され過ぎているため、様々なテーブルとJOINし、様々なwhere句を使っているリポジトリのメソッドがあります。 このリポジトリのメソッドは以下の課題を持っています。 1.集約に関係しないリポジトリからもインターフェイスを介さず、直接呼ばれている 2.クエリが複雑過ぎて保守出来ない(改修した時の影響が見切れない) 性能要件に抵触したため、リファクタリングすることになりました。 まずは単体テストを書いて、想定できるケースは網羅しました。 この後どのようにリファクタリングを進めるべきでしょうか？ また、どの程度までリファクタリングするのがコスパが良いでしょうか？

書籍でモデリングのオススメとしてユースケース図とドメインモデル図を用いてモデリングする手法を紹介していますが、現在の松岡さんの所属組織や支援組織でもユースケース図とドメインモデル図が基本なのでしょうか？他の手法を選んでいる場合はどういった利点があり別手法を選定しているのか聞いてみたいです。よろしくお願いします。

いつもお世話になっております。 生成AIを利用したアプリケーションでプロンプトの扱いに関して質問させてください。 特定フォーマットのデータセットを用意し、セットのプロンプトを生成AIのAPIに渡してサマリーやレポーティングをするようなサービスがあります。 この時に、アプリケーションに組み込むため構造化レスポンスを必ず使うのですが、それに合わせた出力をさせるプロンプト設計を行います。 こういったアプリケーションでプロンプトが１種類しかないためソースコード中にハードコートしようとしているのですが、これの置き場に関していくつか考え方があるように思いまあるように思います。 1. プロンプトはそのままドメイン知識でありビジネス要件とセットの手順書だから、自然言語で書かれたドメインサービスとして扱うべきでは？ 2. プロンプトも構造化レスポンスのスキーマもプリミティブ値の延長なのだから、 ValueObjectとして管理してしまってもいいのでは？ 3. 特定のユースケースでしか使わないプロンプトなのだからアプリケーションサービスの中に隠蔽してしまってもいいのでは？ 4. 生成AIという外部の領域に依存するものだからインフラ層側に書いて、特定の知識のレスポンスを返してくる外部サービスのように見せてしまうのは？ といったように幾つも思いつきます。 単純に文章量が多いため、読みやすさの観点でも切り分けて管理したいのですが、どのように考えるのが良いでしょうか？ ご意見いただけますと幸いです。