2024年04月23日

質問者さん

DDDを導入したく考えています。 ただ更新系をリポジトリパターンに全て当てはめるのはコード量、労力的に厳しいです。 一部のドメインのみリポジトリパターンで更新していくよう考えているのですが、他の更新系はどのように考えていけばよいでしょうか

2024年04月23日

松岡@ログラス/DDD,アジャイル

松岡@ログラス/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,アジャイル

DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw

松岡@ログラス/DDD,アジャイルさんが

最近答えた質問

03月03日

ユーザー詳細画面のページビュー表示用のapiがあります。 データを返す処理は他のapiが担当しており、このapiは実処理らしい処理はありません。 ただ、権限外や条件外(ユーザーがBANされているなど)の場合は弾く必要があります。 しかし権限などのチェックをするだけではusecaseとは呼べないと思います。 とはいえコントローラでDBアクセスするわけにはいきません。 このような場合、どうすればよいのでしょうか。

03月03日

仕様駆動開発やAI駆動開発時のDDDのあり方を質問させてください。 いつも勉強になるお話ありがとうございます。 最近松岡さんが仕様駆動開発について講演されているの拝見いたしました。 その中でDDDについて触れられていない印象を受けました。 仕様駆動開発を行う場合でもDDDは重要だと考えておりますが、DDDの集約やコンテキストの抽出は、仕様駆動開発を行う前か、それとも仕様駆動開発の中で行っていますでしょうか? ご回答お願いいたします。

01月19日

クエリサービスのあり方について質問です。 現在とあるゲームを開発しており以下のようなディレクトリ構成を取っています。 User ├── Domain ├── Application ├── Infrastructure └── Presentation Score ├── Domain ├── Application ├── Infrastructure └── Presentation スコア一覧画面の構成としては 1. ユーザー名(部分一致)でユーザーを検索する 2. 条件に合致したユーザーが一覧で表示され、その中から一人を選択する 3. そのユーザーのスコア一覧が表示される というものになっています。 上記の1の処理においてユーザーを検索する際に 「年齢が18歳以上、検索表示を許可、ステータスが有効」 という条件が暗黙的に設定されます。 これはスコア一覧画面固有の条件です。 また、検索表示許可はオプションのようなものでありユーザー集約に含まれていません。 この場合 案A Score配下のクエリサービス内にユーザーを絞り込む処理を記載する。  →Score内のクエリサービスなのにスコアに関係ないクエリが含まれてしまってよいのか 案B User配下のクエリサービス内にユーザーを絞り込む処理を記載する。  →そのクエリサービスのインターフェースはすでにUser/Applicationにある。スコア用の固有の条件を持つのにここに配置してよいのか。 のどちらがよいのでしょうか。 (あるいはどちらも間違いでしょうか)