DDDの後のアプリケーションでは、Services + Repositories +リポジトリとサービスのインタフェースを含むサービスレイヤーを持つ傾向があります。これらはすべて同じアセンブリ内にあり、ドメインモデルは別のアセンブリに存在します。この1つの大きなプロジェクトでは、ドメインモデルに適合しないものはすべて混乱しているように感じます。DDDでのリポジトリとそのインタフェースのパッケージ化
DDDの原則とパターンに従うアプリケーションでは、リポジトリと実装するインターフェイスをどのようにパッケージ化しますか？ DDDアプリケーションの異なる論理部分をパッケージングするためのベストプラクティス（または一般にパッケージング）は何ですか？すべての論理パーティションは、それ自身のアセンブリに存在する必要がありますか？それは問題なの？
私はオニオンアーキテクチャを見ます。基本的に、ドメインサービスのドメインモデルとインターフェイスはすべてコアと見なされます。レイヤーは、コアの近くのレイヤーにのみ依存します。実際の実装はインフラストラクチャによって処理されます。
最終的にあなたのインターフェイスは、あなたのアプリケーションを定義するものですここhttp://jeffreypalermo.com/blog/the-onion-architecture-part-1/
を参照してください。それがどのように実装されるかの論理は、外部化されています。だから私はあなたがドメインモデルとドメインサービス、フロントエンド（例えばMVCなど）、そしてデータを提供するためのNHibernateのようなものを実装するインフラストラクチャアセンブリを持つアセンブリを持つことを期待します。
リンクされた記事のさまざまな部分のアーキテクチャ。最も簡単な1がここhttps://bitbucket.org/jeffreypalermo/onion-architecture/get/1df2608bc383.zip
であるあなたはここでそれに関連する質問を見ることができますhttps://stackoverflow.com/questions/tagged/onion-architecture
主な利点は、大部分が最も頻繁に変更されるインフラの問題であるということです。新しいデータレイヤ技術、新しいファイルストレージなど。また、コアドメインは、必要なものを契約（インタフェース）で定義するだけのものを実装していないため、合理的に安定している必要があります。実装上の問題を1か所に配置することで、アセンブリ全体で必要となる変更の量を最小限に抑えることができます。
DDD bookにレイヤーを設計するためのガイドラインがあります。あなたは基本的に持っている：
サービスは3種類があります：によって、アプリケーション層サービス、インフラストラクチャ層サービスとドメイン層サービスサービスが何をするかについて。リポジトリに関しては、コントラクト（インフラストラクチャ）がインフラストラクチャレイヤにある間、契約（インターフェイス）はしばしばドメインに存在します。
アセンブリに関しては、1つのレイヤーにつき少なくとも1つを推奨します。アセンブリとdllはすべて再利用性、懸念の分離とデカップリングに関するものです - 私はそのdllを選んで別のアプリケーションで再利用するためにドロップできますか？他のアプリケーションに不必要な複雑さをもたらす無関係の機能をドラッグしないで、私はそうすることができますか？私は、私の依存性注入モジュールで1行のコードを変更するだけで、別のDLLを簡単に置き換えることができますか？等々。
私がまったく気づいていなかったタマネギの建築についての素晴らしい言及。ありがとう。 – kabaros