DDD / Presenter pattern VS Use case optimal query

Question

In this great book about Domain-Driven Design, a chapter is dedicated to the user interface and its relationship to domain objects.

One point that confuses me is the comparison between Use case optimal queries and presenters.

The excerpt dealing with optimal queries (page 517) is:

Rather than reading multiple whole Aggregate instances of various types and then programmatically composing them into a single container (DTO or DPO), you might instead use what is called a use case optimal query.
This is where you design your Repository with finder query methods that compose a custom object as a superset of one or more Aggregate instances.
The query dynamically places the results into a Value Object (6) specifically designed to address the needs of the use case.
You design a Value Object, not a DTO, because the query is domain specific, not application specific (as are DTOs). The custom use case optimal Value Object is then consumed directly by the view renderer.

Thus, the benefit of optimal queries is to directly provide a specific-to-view value object, acting as the real view model.

A page later, presenter pattern is described:

The presentation model acts as an Adapter. It masks the details of the domain model by providing properties and behaviours that are designed in terms of the needs of the view.
Rather than requiring the domain model to specifically support the necessary view properties, it is the responsibility of the Presentation Model to derive the view-specific indicators and properties from the state of the domain model.

It sounds that both ways achieve the construction of a view model, specific to the use case.

Currently my call chain (using Play Framework) looks like:

For queries: Controllers (acting as Rest interface sending Json) -> Queries (returning specific value object through optimal queries)

For commands: Controllers (acting as Rest interface sending Json) -> Application services (Commands) -> domain services/repositories/Aggregates (application services returns void)

My question is: if I already practice the use case optimal query, what would be the benefit of implementing the presenter pattern? Why bother with a presenter if one could always use optimal queries to satisfy the client needs directly?

I just think of one benefit of the presenter pattern: dealing with commands, not queries, thus providing to command some domain objects corresponding to the view models determined by the presenter. Controller would then be decoupled from domain object. Indeed, another excerpt of Presenter description is:

Additionally, edits performed by the user are tracked by the Presentation Model.
This is not the case of placing overloaded responsibilities on the Presentation Model, since it's meant to adapt in both directions, model to view and view to model.

However, I prefer sending pure primitives to application services (commands), rather than dealing directly with domain object, so this benefit would not apply for me.
Any explanation?

Answer 1

Just a guess :)

The preseneter pattern could reuse your repository's aggregate finder methods as much as possible. For example, we have two views, in this case we need two adapters(an adapter per view), but we only need one repository find method:

class CommentBriefViewAdapter {
    private Comment comment;

    public String getTitle() {
         return partOf(comment.getTitle()); 
         //return first 10 characters of the title, hide the rest
    } 
    .....//other fields to display
}

class CommentDetailViewAdapter {
    private Comment comment;

    public String getTitle() {
         return comment.getTitle();//return full title
    } 
    .....//other fields to display
}

//In controller:
model.addAttribute(new CommentBriefViewAdapter(commentRepo.findBy(commentId)));
// same repo method
model.addAttribute(new CommentDetailViewAdapter(commentRepo.findBy(commentId)));

But optimal queries is view oriented(a query per view). I think these two solutions are designed for none-cqrs style ddd architecture. They're no longer needed in a cqrs-style arichitecture since queries are not based on repository but specific thin data layer.