DDD Concepts in N-Layer Development

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!

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.