In Domain-Driven Design, can you use your domain entities in your UI?

Question

In many leading DDD projects, especially MVC style, I see the UI using display objects that mirror domain entities, rather than using those domain objects directly. This style

Answer 1

DDD is a way of thinking while designing a software that starts with modelling the domain. As the webpage puts it:

Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

One thing that follows naturally out of this design pattern is a layered architecture. As it is said in DDD Pattern Summaries

Partition a complex program into LAYERS. Develop a design within each LAYER that is cohesive and that depends only on the layers below. Follow standard architectural patterns to provide loose coupling to the layers above. Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code. The domain objects, free of the responsibility of displaying themselves, storing themselves, managing application tasks, and so forth, can be focused on expressing the domain model. This allows a model to evolve to be rich enough and clear enough to capture essential business knowledge and put it to work.

Whether you need to have display objects to do that? That is just one way of implementing this, but might not even be the best to provide loose coupling. As for an example: maybe the view layer is but a webbrowser and xlt files to visualize xml files emmitted by the business layer? If anybody has more fitting examples, please add them. My point is that DDD stresses a layered architecture, but does not limit this to one possible solution.