I've been thinking about a problem for a while and I don't really feel that I've nailed how to approach this.
I'm trying to work with DDD as much as possible but some presentation scenarios do not really fit with this in terms of performance.
Let's say that we have a system for rental cars, and there we have a view that should display all cars and the number of times they have been rented out.
In a DDD-world I guess I would have a repository for my rental cars and some repository for "rent outs". I also guess that there might be a service that handles the interaction between them, creating agreements etc.
But when it comes to presenting the view with rental cars and the number of rent outs, I'm not really sure where to put this. Since the requirements are very specific to this view, I guess that the most performant version would be to have some kind of "RentalCarsOverview"-object returned by the repository. But this would "pollute" the repositories with queries that are very view-specific.
So I'm wondering if anyone have faced the same issues and how it was solved? I've been looking at CQRS to separate this, using queries for these kind of views and my domain model for updates. Is this a good approach?
Also, would it be "ok" to just have raw SQL in these query-handlers or would one also abstract these with a underlying repository?