現在、Imは全く分離していないプロジェクト（asp.net mvc）をリファクタリングしようとしています。ただフォルダ：■asp.netの幾分大規模なウェブサイトのための推奨される解決構造
がたくさん。
私は、プロジェクトが取り組まなければならないさまざまな責任をより明確にしたいと考えています。これを達成する良いプロジェクト構造に関するアドバイスをいただければ幸いです。
助けてください。事前
で おかげで私は、ドメイン駆動設計（DDD）は、次のことをお勧めし、一つは、このアウトを敷設する方法は、次のプロジェクトを作成することになる提案：
Company.Project.Web < - あなたのMVCアプリケーションを、あなたはまだすることができてもWebフォーム Company.Project.Domain <を使用する - データ転送オブジェクト（DTOの）、のviewmodels、ビジネスロジック、イベント Company.Project.Data < - リポジトリのインターフェイス
Company.Project.Data.EF < - 耳鼻咽喉科リポジトリ Company.Project.Model <のityFramework具体的な実装 - あなたのEF CodeFirstクラス
Company.Common < - ユーティリティおよび/または拡張
の一般的なプロジェクトで、私はあなたがパターンからプロジェクトシルクhttp://silk.codeplex.com/を見てみることをお勧めし、練習チーム。 DDD、リポジトリ、MVC、HTML 5とjQuery（vNext）のミキシングの優れたリファレンス実装。
jdmontyと同様の設計ですが、少しシンプルです。 - MVCアプリケーション
Webプロジェクトはサービスプロジェクトに依存しているため。サービスプロジェクトはドメインプロジェクトに依存しています。
このアドバイスをいただきありがとうございます。それはきれいに見えます... ViewModelsをどこに保存するかについてもう少し詳細を教えてください... ...彼らはサービスプロジェクトとやりとりしますか？ – ignaciofuentes
あなたが言及したように、彼らはサービス層と全く対話すべきではないので、WebプロジェクトにViewModelを保持します。 ViewModelは、ViewとControllerの間でデータを転送するためだけに使用されます。 –
Nick、ビューモデルでDataAnnotationsを使用して検証していますか？もしあなたがそうしていれば、これらのバリデーションもビジネスロジックであると言えるでしょうか？ –
インターフェイスを追加することに同意しました - そして、IoCコンテナを使用して、実行時にインターフェイスを実装に解決することにチャレンジしました。 –
私は、viewModelはサービスレイヤ（ビジネスロジック）と全くやりとりしないと読みました。彼らはWebプロジェクトのままでいけないのですか？ – ignaciofuentes
一般に、ViewModelはWebプロジェクト内に保持されます。しかし、私たちのDTOは、Webやサービス、WPF（XAML）といったプレゼンテーション層で直接使用できます。 UnityのようなIoCコンテナは、私たちの懸念を分離し、サービスの依存関係を注入するために必要です。 – jdmonty