私はドメイン駆動開発に頭を悩ませようとしています。十分な基礎と理解があることを確認したいので、ここで AutoMapper などを使用することをお勧めしません。現在、私のアーキテクチャには次のものが含まれています。
WCF サービスは、永続性 (Entity Framework を使用) とサーバー側の検証を担当します。POCO を DTO に変換し、DTO をクライアントに転送します。
クライアントは DTO を受け取り、それらを POCO に変換します。POCO と DTO を変換するクラスは、サービスとクライアントの間で共有されます。
POCO の実装
IValidatableObjectとINotifyPropertyChangedおよびは、サーバーとクライアントの両方で使用されますが、データ転送には使用されません。DTO は、動作を含まない単なるプロパティ バッグです。
(1)質問 #1。このアーキテクチャはドメイン駆動設計に適していますか?
(2)質問 2。POCO にナビゲーション プロパティを含めることは適切ですか? POCO が DDD アーキテクチャにナビゲーション プロパティを含むことは、私にとって本当に間違っていると感じています。シリアル化されているかどうかにかかわらず、ナビゲーション プロパティを持つことは意味がないからです。特殊な DTO を持つ方が理にかなっています。
たとえば、これは私のアーキテクチャでの POCO/DTO の外観です。
// Enforces consistency between a POCO and DTO
public interface IExample
{
Int32 Id { get; set; }
String Name { get; set; }
}
// POCO
public class Example : IExample, INotifyPropertyChanged, IValidatableObject
{
private int id;
private string name;
public Int32 Id {
get { return this.id; }
set {
this.id = value;
OnPropertyChanged("Id");
}
}
public String Name {
get { return this.name; }
set {
this.name = value;
OnPropertyChanged("Name ");
}
}
public ICollection<Example2> ChildExamples {
get { ... }
set { ... }
}
// INotifyPropertyChanged Members
// IValidatableObject Members
}
// DTO
public class ExampleInfo : IExample
{
public Int32 Id { get; set; }
public String Name { get; set; }
public ICollection<Example2Info> ChildExamples { get; set; }
}
ただし、必ずしもナビゲーション プロパティが必要なわけではなく、空の (null) オブジェクト (またはコレクション) を持つことはオブジェクト指向アーキテクチャでは非常に間違っているように思われるため、正しくないように思えます。また、深いオブジェクト階層のシリアル化と変換を行う必要がある場合もありますが、これは簡単なことではありません。特殊化された DTO のほうが理にかなっているため、シリアル化または入力が必要な場合と必要でない場合がある空のナビゲーション プロパティが常に発生する可能性があるという問題はありません。
public class ComplexInfo
{
public Example ExampleInfo { get; set; }
public ICollection<Example2Info> ChildExamples { get; set; }
}
これらの状況は、実際のエンタープライズ DDD スタイル アーキテクチャではどのように処理されますか? また、ここで他にどのようなアドバイスを与えることができますか?