質問者さん
DDDを導入したく考えています。
ただ更新系をリポジトリパターンに全て当てはめるのはコード量、労力的に厳しいです。
一部のドメインのみリポジトリパターンで更新していくよう考えているのですが、他の更新系はどのように考えていけばよいでしょうか
2024年04月23日
松岡@ログラス/DDD,アジャイルさん
新規か既存かで事情が分かれます。
新規プロダクトであれば、リポジトリパターンで統一することをお勧めします。変にハイブリッドにするとあとから複雑度が増して逆に大変になります。
既存の場合は移行期間としてハイブリッドにするしか選択肢がない、と言うことになります。その場合は、意味的にまとまりのあるところからリポジトリパターンに置き換えていく、しかないですね。テストで守りながら、その中でリファクタリングしていきましょう。
ちなみに、DDDを導入、と言うことであればモデリングから始めるのはお勧めですよ！モデリングは小さなコストで実施できる割にリターンが大きいです。
DDDはモデリングと実装パターンの両方が掛け算で効果を生み出しますが、実装パターンを使用しなくても、モデリングだけでも効果が得られます。こちらの動画・記事を参考にしてみてください。
https://www.youtube.com/watch?v=HgtCKlOzRiQ&t=4s
https://little-hands.hatenablog.com/entry/2022/06/01/ddd-modeling
松岡@ログラス/DDD,アジャイルさんに 質問してみましょう！
松岡@ログラス/DDD,アジャイル
DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw
松岡@ログラス/DDD,アジャイルさんが
最近答えた質問
12月21日
データ量がかなり膨大、かつ正規化され過ぎているため、様々なテーブルとJOINし、様々なwhere句を使っているリポジトリのメソッドがあります。
このリポジトリのメソッドは以下の課題を持っています。
1.集約に関係しないリポジトリからもインターフェイスを介さず、直接呼ばれている
2.クエリが複雑過ぎて保守出来ない(改修した時の影響が見切れない)
性能要件に抵触したため、リファクタリングすることになりました。
まずは単体テストを書いて、想定できるケースは網羅しました。
この後どのようにリファクタリングを進めるべきでしょうか？
また、どの程度までリファクタリングするのがコスパが良いでしょうか？
12月21日
書籍でモデリングのオススメとしてユースケース図とドメインモデル図を用いてモデリングする手法を紹介していますが、現在の松岡さんの所属組織や支援組織でもユースケース図とドメインモデル図が基本なのでしょうか？他の手法を選んでいる場合はどういった利点があり別手法を選定しているのか聞いてみたいです。よろしくお願いします。
12月21日
いつもお世話になっております。
生成AIを利用したアプリケーションでプロンプトの扱いに関して質問させてください。
特定フォーマットのデータセットを用意し、セットのプロンプトを生成AIのAPIに渡してサマリーやレポーティングをするようなサービスがあります。
この時に、アプリケーションに組み込むため構造化レスポンスを必ず使うのですが、それに合わせた出力をさせるプロンプト設計を行います。
こういったアプリケーションでプロンプトが１種類しかないためソースコード中にハードコートしようとしているのですが、これの置き場に関していくつか考え方があるように思いまあるように思います。
1. プロンプトはそのままドメイン知識でありビジネス要件とセットの手順書だから、自然言語で書かれたドメインサービスとして扱うべきでは？
2. プロンプトも構造化レスポンスのスキーマもプリミティブ値の延長なのだから、 ValueObjectとして管理してしまってもいいのでは？
3. 特定のユースケースでしか使わないプロンプトなのだからアプリケーションサービスの中に隠蔽してしまってもいいのでは？
4. 生成AIという外部の領域に依存するものだからインフラ層側に書いて、特定の知識のレスポンスを返してくる外部サービスのように見せてしまうのは？
といったように幾つも思いつきます。
単純に文章量が多いため、読みやすさの観点でも切り分けて管理したいのですが、どのように考えるのが良いでしょうか？
ご意見いただけますと幸いです。