MVVM、DDD、およびWPF階層化アプリケーションプロジェクトの構造ガイダンス

私はVSでアプリケーションの構造を設定しようとしていますが、合理的なレベルに「試して」将来的に証明したいと思います。このアプリケーションは、慣例に従わなかった古いWinformアプリをWPFで書き直したものです。レイヤー、ティア、頭字語などはありません...

これはかなり大規模なエンタープライズアプリケーションです。私のDBがそうであるように、Linq To SQLを使用する予定であり、ほとんどの場合、常にMS SQLになります。また、既存のスキルセットがあります。

できる限りMVVMとDDDをフォローしたいのですが、これらを組み合わせるとアプリケーションの構造が混乱します。いくつかの例を使って説明してみましょう。

MVVMに従うと、フォルダー構造は次のようになります。

Views
Models
ViewModels
Helpers

しかし、私のプロジェクト構造がこれに似ているかもしれない単純化されたDDD階層化アプローチにどのように適合しますか：

MyApp.UI
MyApp.Domain
MyApp.Data

Modelsドメインレイヤーに配置するのPersonですか、それともsayの3つのバージョンがありますか？これは、リポジトリとDBオブジェクトのドメインオブジェクトへのマッピングをどこに配置するかという別の質問につながりますか？私はデータを仮定します...

Views私はUIに行くだろうが、ViewModelsまただろうか？

最後に、ビジネスロジックをどこに埋め込むか。

CodePlex、DDD Exampleで以下を見つけましたが、いくらか助けになりましたが、Webアプリのように思えますが、それは問題ではなく、私の無知が輝いています。

誤解しないでください。フォルダをいくつでも持つことができ、好きな名前を付けることができます。私は、これらの場所が必ずしも呼ばれているものではなく、これがスケーラブルになるように、物を置く場所を見つけようとしています。

私の質問の核心はこのように示されるかもしれません。によって生成されたオブジェクト
がありtblPersonます*.dbml。これは明らかであり、「データ」レイヤーに属します。
これで、Model、DTO、Domain Model、またはと呼ばれる別のLayer（project？）で呼び出されるものがありPersonます。私はどこに置くべきかわからないことのMapperためPersonに必要になるでしょうtblPerson。
次に、ViewModelをEditPerson取得しPersonます。たとえば、それから取得する独自のプロパティがありますが、それ以上の場合もあります。
最後に、そのViewModelにバインドされたビューがあります。

その段落が私の仮定と推測で満たされていることを明確にするために、誰かが私のために空気をきれいにするのを手伝うか、そこから洞察を提供してくれることを望んでいます。

MVVMはUIパターンであり、クライアントで使用されます。

クライアントで使用されるDDDのドメインの部分は、おそらく（の一部）モデルです

ViewとViewModelはクライアントのみです。

Modelをバックエンドに同期するため、RepositoriesをModel（またはその近く）に配置します。

はい、これにより多くの場合、異なる名前空間に複数のPersonクラスが作成されます。開始は非常に似ているかもしれませんが、2、3回の反復またはリリース後に非常に異なる結果になる可能性があります。

編集

リポジトリに関する部分を明確にし、ビジネスロジックの位置付けについてさらに説明する

個別のクライアントとサーバー側/バックエンドのリポジトリを含むシステムを作成する場合、クライアントとサーバーでリポジトリを使用できます。クライアントでサーバーの抽象化を提供し、サーバーで他のサーバーとデータソースの抽象化を提供します。それは単なるパターンです。

ビジネスルールについては、クライアントでそれらを使用する場合は、サーバーでも同様に適用するようにしてください。クライアントを信頼しないでください。クライアントのビジネスルールにより、迅速な入力検証が可能になり、サーバーへのラウンドトリップが防止されます。

DDDはサーバー側に属し、クライアントに「リーク」すると考えています。

あなたは持っている右方向を WPFアプリケーションのMVVMデザインパターンを選択する際に。

Do I put the Models in the Domain layer?

はい、モデルをドメインに配置できます

Where would I put my Repository and mappings of DB Object to Domain Object?

リポジトリは、ドメインが配置されているレイヤーに配置できます。マッピングオブジェクト（DTO-ドメイン転送オブジェクトとも呼ばれる）はサービスレイヤーに配置する必要があります。強力なマッピングツールAutoMapperを使用して、ドメインオブジェクトをDTOに簡単にマッピングできます。

ViewModels also?

ViewModelsは、クライアント側（レイヤー）に配置する必要があります。ビューに応じて、1つ以上のDTOからビューモデルを構築できます。

DDDについては、これについて読んで、ドメイン駆動設計パターンが本当に必要であるかを明確にすることをお勧めします。ここでは、すべてのソフトウェアアプリケーションの95％が「DDDの使用にはあまり適していません」カテゴリに分類されるという議論があります。

編集：上記の参照が追加され、@ Denに感謝します！

どこに行くかを詳しく調べる前に、各層が何をすべきかについて話しましょう。

MVVMのセールスポイントは、ビューとビューモデルの結合です。ここでの目標は、ビュー内のロジックを排除することです。
ビューと同様に、モデルはかなり軽量であり、ビューモデルが動作するために必要な情報（データ）にアクセスするためにのみ使用される必要があります。モデルは異なるデータソースへのアクセスをブレンドできますが、ビジネスロジックを持たないようにする必要があります。ほとんどの場合、ヒットする単一のデータストアがあります。場合によってはそうしません。そうしない場合は、モデルを使用してVMからのデータのソースを不明瞭にすることが適切です。

MVVMの暗黙のポイントは、データが既に保存されており、プロジェクトがその組織を維持する責任を負わないことです。いくつかのプロジェクトは、その仮定を逃すのに十分幸運であり、私が取り組んだほとんどのプロジェクトはそれほど幸運ではありませんでした。データは、私たちが取り組まなければならない別のレイヤーであると言えば十分です。

私のプロジェクトは次のようにレイアウトします。

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

このレイヤーは必要に応じて追加できます。

 project.Helpers

ヘルパーをスタックの残りの部分から分離するので、アプリケーションスタックのレイヤーとして混乱しないようにします。

免責事項：私はDDDの専門家ではありませんが、一般的な要点を理解し、アプローチの価値を理解しています。

あなたのドメインは、あなたが検討している問題のセットになるでしょう。ドメインモデルを作成したことのviewmodelsに主に対応しようとしています。ビュー内で少し。Model / DataStructs内の小さなチャンク。

それでどうやってうまくいくのでしょうか？
IF既存のデータ構造を変更する機能を持っている、そしてあなたが作成した新しいものは、あなたが解決しようとしている問題に相関すべきです。顧客オブジェクトを取得しましたか？次に、顧客に関連する/いくつかのテーブルが必要です。請求書または製品を入手しましたか？同じ話-それらのビジネスオブジェクトにマップするテーブルと構造を作成する必要があります。

ドメインは、ViewModelオブジェクトとそれらのオブジェクトの表示を通じて表現されます。顧客レコードを編集する必要がある場合は、そのタスクを処理するためのVMがあります。

あなたの質問に：

1. DDDをMVVMにオーバーレイしようとしないでください。うまくいきません。DDDはレイアウトパターンではなく、問題全体を表示するためのアプローチです。
2. リポジトリとマッピングは、必要に応じてproject.Dataまたはproject.Modelのいずれかに存在します。
3. それがあなたがproject.Viewsと呼びたいものでない限り、UIと呼ばれる層を持ってはいけません。
4. ビジネスロジックは、ビューモデルに入ります。