ドメイン&のサービス層がどのくらい薄く/厚いかによって、DDDについての正しい方向に進んでいます。 DDDは知識（すなわちビジネスロジック）をドメインモデルに組み込むべきだと述べています。データアクセスの問題をDALに移すことはDDDと一致していますが、ビジネスロジックをサービスレイヤに移動することはできません。薄いドメインの "データモデル"レイヤー（主にエンティティ用）と太いサービスレイヤー（主に "ビジネスロジック"用）がある場合、anemic domainがあります。
また、DDDには技術的に「サービスレイヤー」はありません。 「アプリケーションレイヤー」が存在する可能性がありますが、それは薄く、アプリケーションフロー/ドメインクラスのライフタイムの管理のみに責任があります。これは本質的に、.NET MVCでControllersを実行し、Web httpのコンテキストでアプリケーションフローを管理します。
モデル内のすべてのロジックを詰め込んでコードが複雑すぎる場合は、「過度に複雑」という意味の例を聞くことに興味があります。複雑なドメインを正しくモデリングすることができます。複雑なドメインをモデリングすることもできますし、DDDパターンを使用して複雑な問題を解決する可能性もあります。私はあなたの質問に列挙した通り、アーチはDDDではないと言います。私はそれを「レイヤードアーキテクチャ」と呼んでいますが、それは物理的なアーチについて話すときだけ用語「層」を使用する方が好きだからです。ただし、論理アーキテクチャーは階層化されています。
私はダーリンがオニオンのアーチにリンクしているのが本当に好きです。私はそれの大ファンになりつつあり、DDDだけではないことがわかります。あなたのコードが依存関係インジェクションを使用して実行時実装とのインタフェース依存関係を解決する場合、あなたはオニオンアーチのフォームを持つかもしれません。たとえば、DALにインターフェイスを定義していますか？これらのインタフェースの実装は実行時に解決されますか？
私は新しいプロジェクトで使用し始めているアーチの例です。
APIプロジェクト/組立：：他のすべての層で使用される一般的なインタフェース、列挙型、クラス、および拡張メソッドはタマネギ+ DDDの組み合わせです。ドメインから分離する必要はありませんが、必要に応じて行うことができます。
Domainプロジェクト/アセンブリ：すべてのエンティティとビジネスロジック。 APIにのみ依存します。ファクトリ、サービス、仕様、リポジトリなどのDDDパターンを使用します。また、APIで定義されていないドメイン固有のインタフェースが多く含まれています。
Implプロジェクト/アセンブリ：APIとDomainで定義されたインタフェースの実装。これは、EF DbContextが実装されている場所、ロギング、電子メール送信などです。これらの実装はすべて依存関係注入型であるため、技術的には複数のImplプロジェクト/アセンブリを持つことができます。
UIプロジェクト/アセンブリ：これはMVCプロジェクトです。コントローラはドメインサーフェスを直接消費し、アプリケーションまたはサービスレイヤーを経由しません。 MVC IoC（コンストラクタインジェクション）を使用して、コントローラによって、ファクトリ、サービス、リポジトリなどのインタフェース依存関係がドメインに注入されます。
私は非常にコアにAPIレイヤーを配置しましたが、APIとドメインプロジェクトを1つにまとめることができました。いずれにしても、タマネギの大きな肉部分はドメインであり、内部に層があります。たとえば、サービスは、エンティティに依存するリポジトリに依存するファクトリに依存することがあります。
Implプロジェクトは、パレルモの図の「インフラストラクチャ」タマネギスキンとして表示されます。これはUIとともに外縁にあり、ドメイン固有の知識は含まれていません。 EFなどを使用して電子メールを送信、格納/取得する方法を知っています。必要に応じて、1つ以上のデータアクセスが可能です。たとえば、データアクセスのためのImpl、メールの処理のためのImplなどです。
MVCにはコントローラとビューがあり、UIとWebアプリケーションのフローに集中しています。ドメイン固有の知識を必要とするものはすべてドメインに委譲され、ドメインクラスはコンストラクタがコントローラに注入されます。つまり、ドメインクラス内のコンストラクタインジェクションされたインターフェイスは、IoCコンテナによって自動的に解決されます。
最後に、APIクラスとドメインクラスで定義されたインターフェイスに対してプログラミングを行うと、ドメインプロジェクトをMVCプロジェクトとは別に単体テストできます。
DDDベースのASP.NET MVCプロジェクトの良い例はありますか？または、あなたが記述するアーキテクチャを利用するもの？私は何のプラクティスが使用されているかを集めることができるように、多くのASP.NET MVCプロジェクトからコードを読み込もうとしてきましたが、それは非常に難しいです。 –
私はあなたのコメントへの返信を投稿する前にこれについてあなたとチャットしたいと思います：http://chat.stackoverflow.com/rooms/9000/danludwig-private-room – danludwig
とても面白い答え！私はどのようにGoogleがこの古い投稿に私を指示したのか分からないが、それは本当に良いです。コードプロジェクトでDDDとオニオンアーキテクチャについての記事を例として書くことができますか？すでにD： – Celdor