Say I have a model Exam. There will be a collection of Question objects containing questions and answers, and a collection of what each student have answered.
I think it is ok for the application layer to give the presentation layer only the bits it need to create the UI. In other words when students are answering questions, the application layer does not present the other students to the presentation layer.
Same idea when the data goes back to the application layer. Questions cannot change, so we send only the students answer back to be attached to the domain model.
IMHO this is according to E. Evans description of the application layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems.
Yes, it does make sense. Not only that, in most scenarios this should be the go-to architecture, in my opinion. The thing is DDD is great in managing complexity while keeping consistency within aggregates and bounded context – the things that occur when something gets changed. And there shouldn’t be any change while reading (displaying) the data, so you get no help from DDD on this part. Moreover, if you use your domain object for providing data to your UI layer, you end up tailoring domain for user interface instead of business domain, and these are different contexts.
Actually there are entire architectures basing on that facts, CQRS being one of them. CQRS has this great idea of keeping two sets of data stores – one tailored to domain model, the other explicitly prepared for reading the data to present on UI (for example).
You might also be interested in this blog post on the repository pattern by Szymon Pobiega – it also follows the idea of separating the write (domain) and read (queries) side.