質問者さん
ドメインモデル貧血症について質問したいです。
バリデーション以外のビジネスロジックが無いマスタデータのようなものをエンティティ化するのはドメインモデル貧血症でしょうか。
例えば、他の集約からID参照される「部署」のようなエンティティを作りました。
プロパティはid, nameのみで、
ドメイン知識としては名前の文字数チェックと名前の変更があります。
上記のようなgetter、setterしか持たないエンティティはドメインモデル貧血症にあたるのでしょうか？
また、このようなエンティティが存在するのは設計が悪いのでしょうか？
2024年02月15日
松岡@ログラス/DDD,アジャイルさん
ドメインモデル貧血症は、「getter/setterしかない」ではなく、「そこに書くべきドメイン知識がクラス外にかかれている」と捉えましょう。
文字数がドメイン知識であればバリデーションもそこに書く必要があります。部署クラス、もしくは部署名クラスに実装しましょう。そうでなければ、ユースケースごとに文字数が異なる(たとえば、新規作成時とこうしんじで異なる)ようなことが発生する可能性が生まれてしまいます。
本当にそこに書くべきドメイン知識が他にないのか？という観点も考えて見るためには、具体的な値を記載してモデリングして見るといいでしょう。モデリングのやり方はこちらの動画、本を見てみてください！
https://www.youtube.com/live/HgtCKlOzRiQ?si=2BTklVOQkOYgGPCY
https://little-hands.booth.pm/items/3363104
松岡@ログラス/DDD,アジャイルさんに 質問してみましょう！
松岡@ログラス/DDD,アジャイル
DDDや設計にお困りの方はDMにてご相談ください。講義、モブモデリングやコーディングなどご要望に合わせた進め方でサポートします(オンライン)。 YouTube: https://www.youtube.com/channel/UCbHtbIUxtfGjrDy1WcqxExw
松岡@ログラス/DDD,アジャイルさんが
最近答えた質問
07月17日
ドメインモデル図の作成について教えてください。
考えられるユースケースが3つあったとして、まず1つ目のユースケースに絞ってドメインモデル図を作成したとします。
その後に2つ目のユースケースに対してドメインモデル図を作成するとき、1つ目を拡張する形で作るのでしょうか？
それとも別個のドメインモデル図として作った方が良いのでしょうか？
07月08日
ドメインモデルのコンストラクタ内でランダム値を生成する設計とテストについて相談です
現在、ドメインモデルのコンストラクタ内で各プロパティのルール検証を行いつつ、特定のプロパティ（紹介コードなど）にはランダムな値を生成しています。
この場合、テストコードで構造体の完全一致を検証することができず、設計とテストの整合性について悩んでいます。
私が考えた案は以下の通りです：
➀ランダム値生成を関数引数として外部から渡す設計に変更（依存注入）
➁構造体全体ではなく、必要なフィールドのみを個別に比較する
➂テスト時のみランダム生成関数にフックを仕込んでモック化する
ただし、③の方法については、今後モックが複数発生しテストが肥大化していく懸念があります。
ご相談したい点
・上記のような状況において、松岡様が考える最も適切な対応方針はどれでしょうか？
・そもそも、コンストラクタ内でランダムな値を生成すること自体が設計としてNGなのかどうかもご意見いただきたいです。
なお、似たようなパターンとして、ユーザーモデルのコンストラクタ内でパスワードのルール検証後にハッシュ化を行っているケースもあり、
こちらも構造体の完全一致によるテストができていない状態です。
07月08日
DB更新でユーザーIDを格納する場合、ユーザーIDは集約に含めるべきですか？
それともリポジトリの実装側でセッションから直接取得しますか？