こちらの質問回答への続きです

14時間前

質問者さん

ご回答ありがとうございます! ドメインモデル図から一通りドメインのクラスを実装して次はインフラ層の実装をしようと思ったときに感じた質問でした。あるユースケースではこのオブジェクトは更新するけどこっちは更新しない。となると集約を分けたほうがインフラ層の実装は楽になりそうだ。ただ、ドメインの知識としては大きな集約の理解のほうが直感的ではある。みたいな場面で悩んでおりました。

14時間前

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

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

なるほど!その場合は集約の切り方に改善点があるかもしれませんね。 そのようになることは自然なことで、設計を進めるにあたって戻って改善することは必要です。 集約の範囲は - 簡潔な記述で確実に整合性を守りたい範囲 - パフォーマンス、排他制御範囲 の2点のトレードオフで決めるので、この観点で検討してみてください。 以下ページに詳しい解説があります! https://little-hand-s.notion.site/91dec09e1416416bb87594d79e06f592

松岡@ログラス/DDD,アジャイルさんに 質問してみましょう!

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

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

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

関連する質問

03月27日

集約の見つけ方について質問です。集約を大きな範囲にした時に、インフラ層の実装がつらくなってきたと言う状況は、集約の範囲を見直すサインになりますでしょうか? あるいは実装が辛いのは技術力不足と捉えるほうが自然でしょうか?

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

最近答えた質問

14時間前

続き質問

ご回答ありがとうございます! ドメインモデル図から一通りドメインのクラスを実装して次はインフラ層の実装をしようと思ったときに感じた質問でした。あるユースケースではこのオブジェクトは更新するけどこっちは更新しない。となると集約を分けたほうがインフラ層の実装は楽になりそうだ。ただ、ドメインの知識としては大きな集約の理解のほうが直感的ではある。みたいな場面で悩んでおりました。

03月27日

集約の見つけ方について質問です。集約を大きな範囲にした時に、インフラ層の実装がつらくなってきたと言う状況は、集約の範囲を見直すサインになりますでしょうか? あるいは実装が辛いのは技術力不足と捉えるほうが自然でしょうか?

03月18日

factory メソッドについて教えていただきたいです。 ある entity が 別の entity のfactory メソッドを持つことはありでしょうか?