09月07日

質問者さん

ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか?

10月16日

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

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

抽象クラスやインターフェースで区分を表すのは悪くありませんが、 「型で表現したい理由」が重要です。 その区分によって振る舞い(メソッドの実装)が変わるならOK。 単なる分類目的ならenumなど値オブジェクトで表現する方が自然です。

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

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

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

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

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

最近答えた質問

10月16日

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

10月16日

ドメインモデルにてモデリングしたエンティティを抽象クラスかインターフェースにして、それを実装するクラスでドメインモデルに出てくる種類、区分を表現するのは良いでしょうか?

10月14日

ドメイン知識の実装について質問です。 ユーザー編集の可否判定に以下のルールがあります: - 編集権限を持ったユーザーのみ編集可能 - 対象ユーザーのステータスが無効の場合は編集不可 - システム設定で編集が許可されていない場合は編集不可 これをドメイン層に実装する際、以下のクラスを考えています: - Userクラス(氏名、ステータス等を保持) - Contextクラス(権限、システム設定等を保持) 実装案: 案A: ドメインサービス public class UserEditService { public boolean canEdit(User user, Context context) { return !user.getStatus().equals("invalid") && context.hasPermission("edit") && context.isEditAllowed(); } } 案B: 各クラスに責任を分散 public class User { public boolean isEditable() { return !this.status.equals("invalid"); } } public class Context { public boolean canPerformEdit() { return this.hasPermission("edit") && this.isEditAllowed(); } } // 使用時 if (user.isEditable() && context.canPerformEdit()) { // 編集処理 } 案C: 一方に他方を渡す public class User { public boolean canBeEditedBy(Context context) { return !this.status.equals("invalid") && context.hasPermission("edit") && context.isEditAllowed(); } } どのアプローチが適切でしょうか? それともいずれも間違いでしょうか