Where does DTOS as InputModel / ViewModel Fit in L

I'm trying to understand where does InputModel and ViewModels fit at the 4 Layer Architecture.

Presentation | Application | Domain | Infrastructure

Given that the Application Layer takes care about exchange data beteween Presentation Layer and Domain Layer, I supposed that, they must live inside this layer, as well the adapter to convert It back to Domain Entity and vice versa.

InputModels, also know as Commands, in ASP.NET MVC they can coincide with ViewModels.

Makes no sense to me ViewModels inside the Presentation. From the Application Layer I should return ViewModels to the Presentation and receive ViewModels to Mapp It back to Domain Entity. If I have ViewModels inside the Presentation, and the presentations refers to Application Layer, I will have a loop reference.

And also, for example, If I have a Presentation build into ASP.NET MVC and I have the necessity to change It for Windows Application I will lost this ViewModels that fit on my requisites, what is a shame, given that I already have everything built in to change the presentation Technology.

I'm reading the book From Dino Esposito and Andrea Saltarello, Microsoft .NET: Architecting for the Enterprise. They don't talk too much about the Application Layer, only say that, this one should Orchestrate Domain Services and Repositories to fullfill User Cases, and to hide Domain from the Presentation.

Is this right? Should I put this DTOs inside the Application Layer? If not, Where does they fit on the Lasangna?

回答1:

DTOs should be defined in whichever of the two layers is higher in the dependency food chain, to avoid circular references. This would mean the Application layer in an Onion / hexagonal architecture, because dependencies point inward -- Presentation references Application. I don't know about other layered architecture styles. Alternatively, you could place DTO's in their own separate layer which would be referenced by the two others and stand above them.

回答2:

DTOs are not part of the problem domain, they're implementation details. So the question is, what part of implementation is using the DTO? Entities in DDD however should exist totally independent of any implementation, and deal only with domain specific business logic.