web-dev-qa-db-ja.com

これは、ドメイン駆動設計の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＃インターフェイスが含まれています。

c#restdomain-driven-design
15
Matt W

このフォルダー構造は、Vaugh Vernonによる有名な Implementing domaindriven design の本に触発されています。

解決：
├WebService （RESTサービスはここにあります）
├WebServiceTests
├アプリケーション （アプリケーションサービスはここにあります）
├ApplicationTests
├ドメイン （エンティティ、VO、ドメインサービス、ドメインファクトリ、仕様、ドメインイベント、リポジトリインターフェイス、インフラストラクチャサービスインターフェイス）
├DomainTests
├インフラストラクチャ （リポジトリ、インフラストラクチャサービスの実装、外部サービスへのアダプタ）
└InfrastructureTests

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

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

22
Songo

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

ただし、エンティティーをリポジトリーから取り出して、それらに対して直接ドメイン（ビジネス）アクションを実行できるはずなので、「内部DTO」の部分ににおいがあるかもしれません。エンティティはDTOだけではありません。

_Dal.Db_が_Biz.Domain,_に依存しないという事実から、ドメインレイヤーがInterfacesプロジェクトのDTO（Repositoriesから返された）とその独自のDomainオブジェクトとの間で何らかのマッピングを行っているという事実から、一種の情報を得ました。これは、典型的な最先端の（== "タマネギ"または "六角形"）DDDアーキテクチャでは正しくありません。ドメインレイヤーが他のプロジェクトを参照するべきではありません。同じ理由で、RepositoryインターフェースはInterfacesではなくドメインで宣言する必要があります。

1
guillaume31