ドメイン駆動型デザインクラスへのアクセスWCFサービスのライブラリ

Question

私は自分のプロジェクトをどのように設定するべきかを明確にするために助けが必要です。次のように私のソリューションの構造は次のとおりです。

Company.DataTransferObjects 
--AdminDTO.cs 
--CustomerDTO.cs 
Company.DataTransferObjects.Helpers 
Company.Infrastructure.DomainServices 
--Admin 
---AdminService.cs 
--Customer 
--CustomerService.cs 
Comapny.Infrastructure.Repositories 
--Admin 
---AdminRepository.cs 
--Customer 
---CustomerRepository.cs 
Company.Domain 
--Admin 
---Admin.cs 
---IAdminRepository.cs 
--Customer 
---Customer.cs 
---ICustomerRepository.cs 
Company.WebServices 
--WebApi.cs 
--IWebAPI.cs 

次のように私の質問は以下のとおりです。

1）私のセットアップはあなたに右見ていますか？

2）DTO。 Webサービスの観点から、DTOはどこに作成されるべきですか？ 独立したクラスライブラリにDTOを作成し、WebServiceから を参照するか、それともWebサービスプロジェクトの一部であるべきですか？

また、私のDTOが私のドメインオブジェクトとどのようにやりとりするべきかはわかりません。 誰かがプログラムの流れの観点からその目的を説明してください。具体的には、WCFサービスをどのように操作するのかについて説明できますか？

3）ドメインサービス。私はまだ、ドメインサービスの目的の周りに私の心を包み込むのに苦労しています。これは、データベースには到達しておらず、直接アクセスできないリポジトリメソッドを必要とする操作上の機能を公開しているのでしょうか？ つまり、ドメインサービスは複数のリポジトリメソッドを操作するメソッドですか？したがって、WCFサービスがリポジトリメソッドを介してアクセスできるデータを呼び出している場合は、その処理が必要です。しかし、複数のリポジトリメソッドの結果であるデータが必要な場合、これはドメインサービスを介して行う必要がありますか？

4）ファサードパターンはDDDアーキテクチャのどこに適合しますか？

私の混乱を許してください、私は理解しようとしています。 WCFサービスからアクセスする必要があることを「何を」教えてもらうと、深刻な助けになります。

ありがとうございます！

Answer 1

ご質問には逆の順序で行く：

4）あなたのWebサービスは、効果的に、あなたのドメインへのファサードです。

3）ドメインサービスは、DBにも当てはまります。通常、これらのサービスは、コードを使用して複数のエンティティを含むものでドメインとやりとりしたり、一連のトランザクションを表すものステップ。一部の人々は、リポジトリがドメインサービスの特別なケースであると考えています（どちらか一方ではなく）。私は通常、自分のサービスを自分のドメインの公開インターフェースと見なします。

2）DTOは通常、物理的な境界を越えている（または最終的にはそうする予定がある）ときに便利です。何かをシリアル化（SOAPメッセージなど）する必要があると思われる場合はいつでも、DTOについて考える必要があります。あなたのケースでは、WCFプロジェクトはDataContractsとしてDTOを使用しますが、内部的にはドメインオブジェクトを使用する可能性があります（ドメインが別のアプリケーションドメインや別の物理ボックスにあると思わない限り）。

1）個人的な好みです。あなたのレイアウトは、私が通常どおり整理する方法とは異なりますが、不合理に見えません。