DTOs right place in a multilayered application

Question

In a multilayered application what is the right place for DTOs (Data Transfer Objects)? There is such opinion DTO is for data storage layer to domain layer communication but inappropriate for domain layer to upper logical levels interaction.

I am deleloping an application with the following layers: data storage, domain, service, presentation. Then what's right way to link service and presentation layers? I suppose opening access to the domain objects from the outside of domain layer is an encapsulation breach, so only way to solve the task is using DTO, but I'm unsure.

Answer 1

Many people (especially DDD enthusiasts) say that DTO's are only for remote invocation, basically to encapsulate those remote objects.

That being said, I really prefer to separate my presentation layer from my service layer as explicitly as possible. The presentation layer needs a lot of isolation from the service layer. Especially with thicker clients being the new norm (Angular web sites, mobile devices, etc). This means that treating your service layer as a remote service is often a good investment. It will likely become a true remote interface over time anyway.

The UI/Service boundary is also usually the place where it is usually most difficult to determine contract breakdowns... Most UI frameworks do a horrible job of identifying breaking changes.