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.

1. 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)
2. 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.
3. 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!