花了几个月学习DDD方法后，我现在已经开始这些概念在我的公司申请到实际的产品。事实上，我一直在负责建立一个适当的和可维护的体系结构为未来的发展。

我们已经决定利用了以下技术：EF4（真的V2），统一

在我获得一直是最有启发性的信息量，不过，我留下了在最佳实践的几个问题：

问题1： 的DTO - 最佳实践的

我有我的域对象（PO​​CO类）。有实施这些类的几种方法。

在传统方法：创建包含公共getter / setter方法​​，验证，及放POCO类;相应的业务逻辑。还可以创建的DTO，并使用映射技术来管理它们。 （Automapper） 在传统 - DTO：创建POCO类，如上述，然而，使用波苏斯作为传输对象。这是我的理解是，业务对象应该永远不会离开域虽然。 混合型：我偶然发现了一个有趣的博客文章中，作者创造了他POCO对象和DTO的。里面他的域对象的，他创造的DTO的实例。这使得更容易维护的你不重复的属性，如在＃1。像这样：

公共抽象类POCOBase＆LT; T>：ValidationBase，IPOCO其中T：DTOBase，新的（）
{

 公共t个数据{获得;组; }

 公共POCOBase（）
 {
     数据=新T（）;
 }

 公共POCOBase（T DTO）
 {
     数据= DTO;
 }
  }

  公共类SomePOCO：POCOBase {}

  公共类SomeDTO：DTOBase

  {

 公共字符串名称{;组; }

 公共字符串描述{获得;组; }

 公共布尔的IsEnabled {获得;组; }
}


//实例
// POCOBase＆LT; SomeDTO> somePOCO =新SomePOCO（）;
// somePOCO.Data.Name =blablabla;
// somePOCO.Validate（）;
//返回somePOCO.Data;

问题2： 什么对象应该由UI /服务层返回

这是DTO的整点。一个非常简单，重量轻，只包含裸露的属性对象。它也不含任何验证的结果吧。如果我在我的序列化的DTO返回给客户端，应假定客户端需要任何验证结果就像一个InvalidRules集合。

例如，假设我正与亚马逊的API。我想补充一本书，我个人商店。如果我尝试不发送其ISBN增加了一本书，服务可能会返回某种响应组，其中包含验证结果的误差。

我缺少的东西？我下的是IM pression（至少从DDD纯粹主义者）的DTO的不应该包含业务逻辑。在我看来，DTO的不能提供足够的信息传输对象。如果不是这样，我需要一个新的类型响应的对象封装了DTO和验证结果。

问题3： 多少国际奥委会太多的

似乎很明显，我认为我应该遵循的金科玉律：

  

确定应用程序的部分   而有所不同，并独立于那些   即保持不变。

对我来说这是有道理的申请的IoC条款。为了减少依赖，我的presentation，业务逻辑和数据访问层都通过IoC容器进行通信。我的应用程序层包含通用接口和抽象。这似乎矫枉过正使用的IoC远不止此。我爱的事实，我可以创建模拟测试库 - 通过简单地改变统一的配置，我可以利用TDD的

。

我希望我已经清楚说明这些问题。感谢您的帮助提前！

解决方案

我会尽量解决您的问题，一次一个。

答1

DTO的正交DDD，因为它们服务于不同的目的在应用程序的体系结构不同的地方。这就是说，DTO的有一个域模型没有立足之地，因为他们没有行为，从而会导致贫血领域模型。

波苏斯与持久性无知是要走的路。杰里米·米勒解释这个概念一个很好的文章。

答2

图层坐域模型的顶部往往会需要返回量身定制为宗旨的问题，他们自己的对象。

有关用户界面，MVVM模式工作得特别好。 This文章介绍MVVM为WPF，但模式也就像在ASP.NET MVC魅力。

有关Web服务，这是那里的DTO模式适用。 WCF数据合同是DTO的，如果你想知道：）

这将需要大量的映射来回的服务接口和领域模型之间，但这是你必须付出的柔性设计的价格。您可能会发现 AutoMapper 的有帮助在此方面。

答3

更IOC（真：DI）向好，但有一件事对你的问题让我吃惊：一个DI容器只能连线了对象图，然后让开了路。对象不应该依赖于DI容器。

请参阅this SO回答了解更多详情。

After spending a couple months studying DDD methodology, I've now began to apply these concepts into actual products at my company. In fact, I've been tasked with creating a suitable and maintainable architecture for future development.

We have decided to make use of the following technologies: EF4 (really v2), Unity

The amount of information I've obtained has been most enlightening, however, I'm left with several questions in best practice:

Question #1: DTOs - Best Practices

I have my domain objects (POCO classes). There are several ways to implement these classes.

Traditional Approach: Create POCO classes which contain public getters/setters, Validation, & appropriate business logic. Also create DTOs and use mapping techniques to manage them. (Automapper) Traditional - DTO: Create POCO classes like stated above, however, use your POCOs as transfer objects. It's my understanding that business objects should never leave the domain though. Hybrid: I stumbled upon an interesting blog post in which the author creates his POCO objects and DTOs. Inside of his domain object he creates an instance of the DTO. This allows for easier maintainability as you're not duplicating your properties like in #1. Like so:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

Question #2: What objects should be returned by the UI/Service Layer?

This is the whole point of the DTO. A very simple, light-weight object containing just the bare attributes. It's also not containing any Validation results in it. If I am serializing my DTOs back to the client, it should be assumed the client needs any Validation results like an InvalidRules collection.

For instance, say I'm working with Amazon's API. I would like to add a book to my personal store. If I try to add a book without sending its ISBN, the service would probably return some kind of response group which contains Validation result errors.

Am I missing something? I was under the impression (at least from DDD "purists") that DTOs should contain no business logic. It seems to me DTOs do not provide enough information as transfer objects. Either that or I need a new type of Response object which encapsulates the DTO and Validation results.

Question #3: How much IoC is too much?

It seems apparent to me that I should follow the golden rule:

"Identify the parts of the application that vary, and separate from those that stay the same."

To me this makes sense in terms of applying IoC. To reduce dependencies, my Presentation, Business Logic, and Data Access layers all communicate via an IoC container. My Application layer contains common interfaces and abstractions. It seems overkill to use IoC much more than this. I love the fact that I can create mock test Repositories - and by simply changing Unity's configuration, I can make use of TDD.

I hope I've stated these questions clearly. Thanks for your help in advance!

解决方案

I'll try to address your questions one at a time.

Answer 1

DTOs are orthogonal to DDD because they serve a different purpose in a different place in an application's architecture. That said, DTOs have no place in a Domain Model because they have no behavior and will thus lead to Anemic Domain Models.

POCOs with Persistence Ignorance is the way to go. Jeremy Miller has a good article that explains this concept.

Answer 2

Layers that sit on top of the Domain Model will often need to return their own objects that are tailored for the purpose in question.

For UIs, the MVVM pattern works particularly well. This article introduces MVVM for WPF, but the pattern also works like a charm in ASP.NET MVC.

For web services, this is where the DTO pattern applies. WCF Data Contracts are DTOs, in case you were wondering :)

This will require a lot of mapping going back and forth between the service interface and the Domain Model, but that's the price you have to pay for Supple Design. You may find AutoMapper helpful in this regard.

Answer 3

The more IoC (really: DI) the better, but one thing about your question struck me: A DI Container should only wire up the object graph and then get out of the way. Objects should not rely on the DI Container.

See this SO answer for more details.