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

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

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

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

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

最近答えた質問

17時間前

ドメイン知識の実装について質問です。 ユーザー編集の可否判定に以下のルールがあります: - 編集権限を持ったユーザーのみ編集可能 - 対象ユーザーのステータスが無効の場合は編集不可 - システム設定で編集が許可されていない場合は編集不可 これをドメイン層に実装する際、以下のクラスを考えています: - 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(); } } どのアプローチが適切でしょうか? それともいずれも間違いでしょうか

17時間前

ドメイン駆動設計本読み直して基幹システム移行に役立てたいと考えています しかしデータオブジェクトやドメインオブジェクトにメソッドを持たせるパターンの判断に慣れないです。 取引履歴を集計してFeeクラスを生成する場合、Feeクラスに自身を生成するメソッドを持たせたのですが、 AIに聞くとそれはAggregatorクラスで独立させるべきと言われてしまいましたが腹落ちしていません 自己分析すると「Feeクラスに書いておけば読むとき便利そう」という思いが強いのかも DDD的にはどのあたりの知識があれば判断できるようになりますか

07月17日

ドメインモデル図の作成について教えてください。 考えられるユースケースが3つあったとして、まず1つ目のユースケースに絞ってドメインモデル図を作成したとします。 その後に2つ目のユースケースに対してドメインモデル図を作成するとき、1つ目を拡張する形で作るのでしょうか? それとも別個のドメインモデル図として作った方が良いのでしょうか?