ASP.NET MVCでのDDD、ビューモデル、および検証

Question

私は最初のDDDアプリケーションを開発しており、ここ数ヶ月で勉強したいくつかの基本的なルールに従っています。

Nhibernateでリポジトリパターンを実装しました。
私はエンティティをコントローラからビューに "移動"させることができたと思っていましたが、すぐに私はそれがほとんど不可能であることを認識しました。

ほとんどの人は、各ビューに固有のビューモデルを定義する方が好きです。
私は、自分のエンティティについて既に作成したフィールドを再定義するという考えは特に気にしませんが、これが唯一の方法だと思われます。

今、いくつかの検証ルールを付けたいという状況に直面しています。
エンティティに検証ルール（DataAnnotations付き）を添付できたと思っていますが、ビューモデルを使用している場合は機能しません。

ここでの質問は以下のとおりです。

• は、検証は、ドメインモデルの一部ではないでしょうか？
• モデルを作成してから、ビューモデルの同じフィールド（プロパティ）を再マップするのに時間がかかりませんか？
• 少なくとも妥当性検査のルールがない場合、これは貧困モデルではありませんか？ DDDが中小規模のアプリケーションに本当に適しているかどうか疑問に思っています。

ご協力いただきありがとうございます。

Answer 1

これは何百回もここに尋ねられています。これは何百回も答えました（これはあなたにこれを尋ねる最初の人物です:-)）：ユーザー検証ロジックをビューモデルに入れますフィールド名、日時書式など）を入力し、エンティティにビジネス検証ロジックを設定します（ユーザー名がすでに取得されている、ユーザーが最大クォータに達しているため、

Answer 2

ドメインモデル の一部ではありませんか？

私はそれがドメインモデルとビューモデルの両方にあるべきだと思います。ビューモデルの検証では、--datetime、decimal、intなどのタイプの入力が有効かどうかを確認しますが、ドメインモデルの検証では、アプリケーション固有のルールをチェックする必要があります。このように、別のUIを使用することを決定したとしても、ビジネス検証は引き続き行われますが、UIは入力検証を処理する必要があります。

それは時間 モデルを作成し、 のviewmodelに 同じフィールド（プロパティ）を再マップするために時間を過ごすために消費しませんか？

これに役立つツールは、たとえばautomapper（コード）です。私の意見では、これはBLLとUIの間のより明確な分離をもたらします。

このアプローチは全体的に時間がかかりますが、スケーラビリティも向上します。将来的にアプリケーションを拡張する必要がある場合は、アーキテクチャを設計する合理的な方法です。