我正试图围绕领域驱动开发。我想确保我有一个良好的基础和理解它，所以如果这里避免使用 AutoMapper 或类似的建议会很棒。我的架构目前涉及以下内容：
WCF 服务负责持久性（使用实体框架）和服务器端验证。它将 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 风格架构中是如何处理的？这里可以提供哪些其他建议？