Понятия DDD в разработке слоя n-типа

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.