09月07日

質問者さん

いつもお世話になっております。DDDを実践していて以下の点が気になりましたので質問させて頂きたいです。 例えば、あるエンティティが、自分が持っている属性ごとに異なる計算(ifやswitch)をしているメソッドがあるとします。(演劇エンティティの場合:タイプがコメディの場合の料金計算処理とタイプがシリアスの場合の料金計算が条件分岐分かれているメソッドを持っている場合など) 今後の改修で演劇タイプがどんどん増えてきた場合、メソッド内の条件分岐もどんどん増えていくことになります。この場合どのようにして保守性をあげれば良いでしょうか? ストラテジやサブクラスによる対応をした時にドメインモデルとの差が出てきてしまい、悩んでおります。ご回答いただけると幸いです

10月16日

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

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

料金計算をどこに置くかは、 「演劇が料金を知るべきか」「料金が演劇を参照すべきか」で決まります。 どちらの責務とする方が適切で自然が、で判断しましょう。 演劇が料金ルールを内包するなら、演劇クラス内に計算メソッドを置く。 一方で、料金が演劇に依存する(タイプなどを参照して計算する)なら、 計算処理は外出しして、演劇を引数に取るクラスに責務を分けると高凝集低結合になり保守性を高めやすいです。 演劇内で行う場合も、タイプごと(コメディ、シリアスなど)に 計算クラスを分けて、演劇クラスではな呼び分けだけ行う形にしておくと、保守性が高まります。

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

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

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

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

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

最近答えた質問

03月31日

続き質問

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

03月27日

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

03月18日

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