質問者さん
ユーザとタグをエンティティとして実装している
ユーザが集約ルート
ユーザ作成時にタグを付与すると、タグが作成される
テーブルはユーザテーブル、タグテーブル、ユーザとタグの関連管理テーブルの3つがある
といった場合、ユーザ作成処理はユーザリポジトリに、タグ作成処理はタグリポジトリに書くのだと思いますが、ユーザとタグの関連を管理する処理はどこに記載すべきでしょうか
2024年04月23日
松岡@ログラス/DDD,アジャイルさん
それは集約の設計に依存します。
画像のパターン①は、ユーザ付与タグというオブジェクトはユーザーエンティティの子オブジェクトとして保持し、ユーザーリポジトリにユーザーエンティティのインスタンスごと渡します。
ユーザー付与タグオブジェクトはタグIDを保持します。
https://gyazo.com/dcdb780629e3633105d4a29bb8b7830a
パターン②の場合は、ユーザー付与タグエンティティはユーザーIDとタグIDを保持し、リポジトリもユーザーリポジトリとユーザー付与タグリポジトリに分かれます。
どのようにしてこのパターンどちらにするかを判断するかと言うと、集約の範囲によるメリットデメリットで判断します。
集約を大きくするメリット
→ 整合性を確保する実装とテストが簡単になる
集約を大きくするデメリット
→処理するデータ量が増える
→排他制御の範囲が大きくなる
集約を跨いだ場合の整合性を確保する実装はこちらをご覧ください。
https://little-hands.hatenablog.com/entry/2021/03/08/aggregation
松岡@ログラス/DDD,アジャイルさんに 質問してみましょう！
松岡@ログラス/DDD,アジャイル
DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw
松岡@ログラス/DDD,アジャイルさんが
最近答えた質問
07月08日
ドメインモデルのコンストラクタ内でランダム値を生成する設計とテストについて相談です
現在、ドメインモデルのコンストラクタ内で各プロパティのルール検証を行いつつ、特定のプロパティ（紹介コードなど）にはランダムな値を生成しています。
この場合、テストコードで構造体の完全一致を検証することができず、設計とテストの整合性について悩んでいます。
私が考えた案は以下の通りです：
➀ランダム値生成を関数引数として外部から渡す設計に変更（依存注入）
➁構造体全体ではなく、必要なフィールドのみを個別に比較する
➂テスト時のみランダム生成関数にフックを仕込んでモック化する
ただし、③の方法については、今後モックが複数発生しテストが肥大化していく懸念があります。
ご相談したい点
・上記のような状況において、松岡様が考える最も適切な対応方針はどれでしょうか？
・そもそも、コンストラクタ内でランダムな値を生成すること自体が設計としてNGなのかどうかもご意見いただきたいです。
なお、似たようなパターンとして、ユーザーモデルのコンストラクタ内でパスワードのルール検証後にハッシュ化を行っているケースもあり、
こちらも構造体の完全一致によるテストができていない状態です。
07月08日
DB更新でユーザーIDを格納する場合、ユーザーIDは集約に含めるべきですか？
それともリポジトリの実装側でセッションから直接取得しますか？
07月08日
リポジトリ層に定義する関数で、オーバーロードを使うべきか否かのご意見を伺いたいです。
update(foo: String), update(bar: Int) とするか、updateFoo(foo: String), updateBar(bar: Int) とするかです。