この場合、2つのタイプの検証を分離する必要があると思います。ドメイン検証とアプリケーション検証。
アプリケーションの検証は、コマンドのプロパティ 'text'が20〜200文字であることを検証するときに行うものです。したがって、これをGUIおよびPOST後にサーバーでも実行されるview-model-validatorで検証します。同じことが電子メールにも当てはまります（ところで、 `32.d +" Hello World .42 "@mindomän.local"などの電子メールはRFCによれば有効であることを理解してください）。
次に、別の検証があります。記事が存在することを確認してください-GUIからコメントを添付するコマンドが送信された場合、記事が存在しない理由を自問する必要があります。GUIは最終的に整合性がとれており、データストアから物理的に削除できるアーティクルという集約ルートがありますか？その場合、コマンドハンドラーは集約ルートのロードに失敗するため、コマンドをエラーキューに移動するだけです。
上記の場合、有害なメッセージを処理するインフラストラクチャがあります。たとえば、メッセージを1〜5回再試行してから、メッセージをポイションキューに移動します。ここで、メッセージのコレクションを手動で検査し、関連するメッセージを再ディスパッチできます。監視するのは良いことです。
さて、ここで議論しました：
アプリケーションの検証
- GUIでJavaScriptを使用
- WebサーバーでMVC検証を使用
集約ルート+ポイズンキューがありません
ドメインと同期していないコマンドについてはどうですか？おそらく、ドメインロジックに、記事への5つのコメントの後、400文字未満のコメントしか許可されないというルールがあるかもしれませんが、1人の男が5番目のコメントで遅すぎて6番目になった-GUIはそれをキャッチしなかったため彼がコマンドを送信した時点のドメインと一致していませんでした。この場合、ドメインロジックの一部として「検証エラー」が発生し、対応するエラーイベントを返します。
イベントは、メッセージブローカーまたはカスタムディスパッチャーへのメッセージの形式にすることができます。アプリケーションがモノリシックの場合、Webサーバーは、前述の成功イベントと失敗イベントの両方を同期的にリッスンし、適切なビュー/部分を表示できます。
多くのタイプのコマンドの失敗を意味するカスタムイベントがあることがよくあり、Webサーバーの観点からサブスクライブするのはこのイベントです。
現在取り組んでいるシステムでは、MassTransit + RabbitMQメッセージバス+ブローカーを介してコマンド/イベントでリクエスト/レスポンスを実行しており、この特定のドメインに（ワークフローの一部をモデル化している）というイベントがありますInvalidStateTransitionError。状態グラフのエッジに沿って移動しようとするほとんどのコマンドは、このイベントを発生させる可能性があります。今回のケースでは、最終的に一貫性のあるパラダイムに基づいてGUIをモデル化しているため、ユーザーを「コマンド承認」ページに送信し、その後、イベントサブスクリプションを通じてWebサーバーのビューを受動的に更新します。また、集約ルートでイベントソーシングも行っていることにも注意してください（sagasの場合も同様です）。
つまり、あなたが話している検証の多くは、実際にはアプリケーションタイプの検証であり、実際のドメインロジックではありません。ドメインは単純ですがDDDを実行している場合は、単純なドメインモデルを使用しても問題はありません。ただし、ドメインのモデリングを続けると、ドメインが最初に判明したほど単純ではない可能性があることに気付くでしょう。多くの場合、集約ルート/エンティティは、コマンドによって引き起こされたメソッド呼び出しを受け入れるだけで、検証を実行することなくその状態の一部を変更する可能性があります-特に、Webサーバーでコマンドを検証する場合のようにコマンドを信頼する場合あなたがコントロールします。
Norwegian Developer Conference 2011の DDDに関する2つのプレゼンテーションと、Öredev2010での Gregのプレゼンテーションをご覧になることをお勧めします。
乾杯、ヘンケ