Yo mismo he luchado con esto. Hay casos en los que tiene sentido utilizar un DTO en la presentación. Digamos que quiero mostrar un menú desplegable de Empresas en mi sistema y necesito su identificación para vincular el valor.
Bueno, en lugar de cargar un CompanyObject que podría tener referencias a suscripciones o quién sabe qué más, podría enviar un DTO con el nombre y la identificación. Este es un buen uso en mi humilde opinión.
Ahora tome otro ejemplo. Tengo un objeto que representa una estimación, esta estimación puede estar compuesta por mano de obra, equipo, etc., puede tener muchos cálculos definidos por el usuario que toman todos estos elementos y los resumen (cada estimación podría ser diferente con diferentes tipos de cálculos). ¿Por qué debería modelar este objeto dos veces? ¿Por qué no puedo simplemente hacer que mi interfaz de usuario enumere los cálculos y los muestre?
Por lo general, no uso DTO para aislar mi capa de dominio de mi interfaz de usuario. Los uso para aislar mi capa de dominio de un límite que está fuera de mi control. La idea de que alguien ponga información de navegación en su objeto comercial es ridícula, no contamine su objeto comercial.
¿La idea de que alguien pondría validación en su objeto comercial? Bueno, digo que esto es bueno. Su interfaz de usuario no debería tener la responsabilidad exclusiva de validar sus objetos comerciales. Su capa empresarial DEBE realizar su propia validación.
¿Por qué pondrías el código de generación de UI en un objeto busienss? En mi caso, tengo objetos separados que generan el código de la interfaz de usuario por separado de la interfaz de usuario. Tengo varios objetos que convierten mis objetos comerciales en Xml, la idea de que tenga que separar sus capas para evitar este tipo de contaminación es tan ajena para mí porque ¿por qué poner código de generación HTML en un objeto comercial ...
Editar
Como pienso un poco más, hay casos en los que la información de la interfaz de usuario puede pertenecer a la capa de dominio. Y esto podría nublar lo que usted llama una capa de dominio, pero trabajé en una aplicación de múltiples inquilinos, que tenía un comportamiento muy diferente tanto en la apariencia de la interfaz de usuario como en el flujo de trabajo funcional. Depende de varios factores. En este caso teníamos un modelo de dominio que representaba a los inquilinos y su configuración. Su configuración pasó a incluir información de la interfaz de usuario (etiquetas para campos genéricos, por ejemplo).
Si tuviera que diseñar mis objetos para hacerlos persistentes, ¿debería también tener que duplicar los objetos? Tenga en cuenta que si desea agregar un nuevo campo, ahora tiene dos lugares para agregarlo. Quizás esto plantea otra pregunta si usa DDD, ¿son todas las entidades persistentes objetos de dominio? Sé en mi ejemplo que lo fueron.