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

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

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