1

コマンドを取得しました:MovePlayerCommand。

このコマンドのバリデーターの 1 つは、次の 3 つのことを行います。

  • プレイヤーが移動するためのコストを計算します (検証のためだけでなく、表示目的でも呼び出すことができます)

  • このコストを検証する

  • 「PlayerMoved」イベントをリッスンして、コストを適用できるようにします (たとえば、10 アクション ポイント)。

これは、単一のクラスに対する責任が大きすぎますか? もしそうなら、これをどのように分離しますか？

編集:コストを削除してチェックすることは2つのことだと知っていますが、このコストの計算からそれらを切り離すことはできず、アクションごとに3つのクラスを持ちたくありません

4

2 に答える 2

1

ここには大きな誤解があります。DDD と CQRS を混ぜてコメントしている人がいるからです。OPはコマンドについて話し、質問にcqrsのタグを付けたので、OPが実際にCQRSでDDDを使用していると仮定します。

ドメイン検証ロジックはコマンド ハンドラーにある必要があります。コマンドがハンドラー スタブに到達する前にデータ チェックを実行する必要がありますが、ドメイン ロジック検証は実行しないでください。つまり、コマンド ハンドラー以外にドメイン ロジックに対してコマンドを検証できる場所はありません。これは、集約が読み込まれる場所だからです。

表示している検証はドメイン検証であるため、実際には集計によって実行する必要があります。そのため、その責任を少し壊して、データとドメインのさまざまな種類の検証を分割する必要があると思います。

于 2013-04-16T13:39:31.287 に答える
1

より多くの情報なしに決定的に答えることは不可能です。

とはいえ、あなたが説明したことはバリデーターのようには聞こえません。一種の「計算機」のように聞こえます。

計算メソッドが 1 つのクラス (電卓クラス) に属し、バリデータ クラスが電卓を参照する可能性があります。

私はドメイン イベントを非常に薄いハンドラー クラスで処理する傾向があり、これは集約ルートまたはサービスに従います (これは一般的な方法ですが、普遍的な方法ではありません)。したがって、ルートまたはサービスは、計算機 (および場合によってはバリデーター) への参照も持っている可能性があります。

この質問は SO には広すぎる可能性があり、DDD フォーラムでより適切に回答される可能性があります。その場合でも、より多くの背景を提供する必要がある場合があります。

于 2013-04-10T22:00:31.270 に答える