これは、ドメイン駆動設計のRESTful Webサービスに適したVisual Studioソリューション構造ですか？

私は.NET 4.5 C＃Web API RESTfulソリューションを構築していますが、ドメイン駆動設計を使用して設計されたソリューションのプロジェクトソリューションが正しいか、賢明であるか（または十分ですか）を教えてください。

ソリューションは6つのプロジェクトに分割されました。

• /ベース

（何にも参照されない）

Webプロジェクトは、ソリューションと外部の世界との間のインターフェースを形成します。Web APIコントローラーが含まれています。要求オブジェクトから値を収集し、BizApiレイヤーに作業を依頼する以外のロジックはほとんど含まれていません。

• /Biz.Api

（ベースで参照]）

ドメインサービスを提供し、/ Baseインターフェイスプロジェクトが/Biz.Domainプロジェクトのドメインビジネスロジックオブジェクトにアクセスできるようにします。

• /Biz.Domain

（Biz.Apiが参照）

Biz.Apiレイヤーのドメインクラスを提供します。これらは、メモリ内のビジネスのデータを操作するメソッドを提供します。

• /Dal.Db

（Biz.Apiが参照）

データベースリポジトリレイヤー。データベースにアクセスし、返されたデータを/ Interfacesレイヤーで定義された内部DTOにマップします。

• /Dal.Services

（Biz.Apiが参照）

Webサービスなどの外部の依存関係にプロキシレイヤーを提供し、返されたデータを/ Interfacesプロジェクトで定義された内部DTOにマップします。

• /インターフェース

（上記のほとんどのプロジェクトで参照）

ソリューションにデータを渡すためのDTOクラスと、IoCなどのコントラクトを定義するC＃インターフェイスが含まれています。

このフォルダー構造は、Vaugh Vernonによる有名なImplementing domain主導のデザインブックに触発されています。

ソリューション：
├Webサービス^{_{（RESTサービスはここに常駐）}}
├WebServiceTests
├アプリケーション^{_{（アプリケーションサービスがここに常駐）}}
├ApplicationTests
├ドメイン^{_{（事業体、VO、ドメインサービス、ドメイン工場、仕様、ドメインイベント、リポジトリのインターフェース、インフラサービス・インタフェース）}}
├DomainTests
├インフラストラクチャ^{_{（リポジトリ、インフラストラクチャサービス実装、外部サービスへのアダプタ）}}
└インフラストラクチャテスト

ソリューションから始めて、アプリケーションの各レイヤーに4つのプロジェクトを作成し、次に各レイヤーのテストに別の4つのプロジェクトを作成します。

フォルダーを作成しないでください。interfacesまたはservices、ドメインレイヤーに関連するクラスをモジュール内の機能別にグループ化する必要があります。

構造に関して"YourProjectWebApi"は"Base"、の"Dal.External"代わりに"Dal.Services"などのように、より自己記述的な別の名前を思いついたとしても、私には問題ないようです。

ただし、エンティティをリポジトリから取得し、それらに対して直接ドメイン（ビジネス）アクションを実行できるようになっているため、「内部DTO」部分に匂いがする場合があります。エンティティはDTOだけではありません。

DomainレイヤーがInterfacesプロジェクト（Repositoriesから返される？）からのDTOとそれ自身のDomainオブジェクトとの間のマッピングを行っているということDal.Dbに依存しないという事実から、私はちょっと集まりBiz.Domain,ます。これは、典型的な最先端（==「タマネギ」または「六角形」）DDDアーキテクチャでは正しくありません。ドメイン層は他のプロジェクトを参照すべきではありません。同じ理由で、RepositoryインターフェースはInterfaces、私が思うようにではなく、ドメインで宣言する必要があります。