DDD Concepts in N-Layer Development

Question

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!

Faubourg

In the future, please state each question as a seperate StackOverflow question... – Selemas

Answer 1

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.

Selemas

Thanks for your comment Mark. It's my understanding that anemic domain models ensue when the domain objects are void of any business logic. They remain bags of getters/setters. Another point of ADM is when logic (such as validation) occurs outside the object rather than contained within. If you look back to Question #1 the Hybrid approach ... to me creating a DTO instance inside a persistent ignorant domain object, doesn't necessarily constitute it an anemic domain model. You're right, in that it breaks DDD principals though. I will probably have to dig into this a little more. – Faubourg

Answer 2 was perfect. I had an inclination that I might need to create custom return objects. Thanks for the advice on MVVM ... will surely take a look. – Faubourg

I'm currently configuring my DI Container in my ASP.NET web.config then using the Global.asax to set it up. For your Answer 3, if I understand you correctly: So to implement TDD methods, I should just simply Register DI configuration within the method itself "on-the-fly"? – Faubourg

To get most out of your DI Container (Unity IIRC), set it up and resolve all root types in global.asax. The important thing to be aware of is that your classes should not depend on the DI Container - they should just depend on their services. – Selemas

BTW, if you find this answer useful, please use the voting buttons - this is what drives StackOverflow. – Selemas

I appreciate your help Mark, I usually just wait a little it to hear from other developers before marking an answer. Unless it works differently here than experts-exchange. – Faubourg

Waiting a while before accepting an answer is a good policy. I just wondered why you didn't upvote the answer if you found it useful, but I forgot that you can't vote until you have 15 points... my mistake, sorry. – Selemas

I usually use a infrastructure layer under my domain. My repos and factory are interface and my infra layer implemente them. To use some kind of ORM I describe my table in DTOs and entity manager. It avoid to dirty my domain class with that annotation. And actually my tables is slightly diferente of my bussines model. I reached a good decouple code. Where my domains is over some technology but can easy migrate to another keeping the business logic. Example when move my domain to a Android app or even another Java server technology. My api also is better represent with my dto object. – Crus