私が取り組んだDDDに続くアプリケーションでは、サービス+リポジトリ+リポジトリとサービスのインターフェイスを含むサービスレイヤーが存在する傾向があります。これらはすべて同じアセンブリに存在しますが、ドメインモデルは別のアセンブリに存在します。この1つの大きなプロジェクトでは、ドメインモデルに適合しないものがすべて散らかっているように感じます。
DDDの原則とパターンに従うアプリケーションでは、リポジトリとそれらが実装するインターフェイスをどのようにパッケージ化しますか？DDDアプリケーションのさまざまな論理部分をパッケージ化する（または一般的にはパッケージ化する）ためのベストプラクティスは何ですか？すべての論理パーティションは独自のアセンブリに存在する必要がありますか？それも重要ですか？
オニオンアーキテクチャを見てみます。基本的に、ドメインサービスのすべてのドメインモデルとインターフェイスはコアと見なされます。レイヤーは、コアに近いその上のレイヤーにのみ依存します。それらの実際の実装はインフラストラクチャによって処理されます。
ここを参照してくださいhttp://jeffreypalermo.com/blog/the-onion-architecture-part-1/
最終的には、インターフェイスがアプリケーションを定義します。それがどのように実装されるかのロジックは外部化されています。したがって、ドメインモデルとドメインサービスを備えたアセンブリ、フロントエンド（MVCなど）、そしてデータを提供するためのNHibernateなどを実装するインフラストラクチャアセンブリが必要です。
リンクされた記事のさまざまな部分で、アーキテクチャを実装するさまざまなサンプルを見ることができます。最も単純なものはここにありますhttps://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip
あなたはここでそれに関連する質問を見ることができますhttps://stackoverflow.com/questions/tagged/onion-architecture
主な利点は、最も頻繁に変更されるのは主にインフラストラクチャの懸念であるということです。新しいデータレイヤーテクノロジー、新しいファイルストレージなど。また、コアドメインは、必要なものをコントラクト（インターフェイス）で定義するだけでは何も実装されていないため、適度に安定している必要があります。実装に関する懸念事項を1つの場所に配置することで、アセンブリ全体で必要となる変更の量を最小限に抑えることができます。
レイヤーを設計するためのガイドラインは、DDDブックにあります。あなたは基本的に持っています：
サービスには、サービスの機能に応じて、アプリケーション層サービス、インフラストラクチャ層サービス、ドメイン層サービスの3種類があります。リポジトリに関しては、それらのコントラクト（インターフェース）はドメインに存在することが多く、具体的な実装はインフラストラクチャ層にあります。
アセンブリに関しては、レイヤーごとに少なくとも1つをお勧めします。アセンブリとdllはすべて、再利用性、関心の分離、および分離に関するものです。そのdllを選択してドロップし、別のアプリケーションで再利用できますか？他のアプリケーションに不必要な複雑さをもたらす無関係な機能の束に沿ってドラッグすることなく、そうすることができますか？依存性注入モジュールのコードを1行変更するだけで、dllを別のdllに簡単に置き換えることができますか？等々。