DDD: Should I Use Entities When Building Reports?

Question

Problem-Based Design

In my application, the repository returns a recordset as a homogeneous entity collection. Entity and repository refer to the same entity, for example, Owner: Repository_Owner will return a collection of objects of the Entity_Owner class.
What if the repository needs to return heterogeneous data? For example, a report or statistics, such as owner data and some numbers for each: how many objects it has, total / average financial indicators, etc.
Or you can create your own entity or value object for each type of report, but then it is difficult to name them properly, because they do not represent anything in the subject area and it is difficult to name them. Report and report.
Or simply return an array and display it as it is - but this is somehow not true, not DDD.
What do you suggest?
(PHP project, but I don't think it's important).

Answer 1

What if the repository needs to return heterogeneous data?

It's probably wrong when a repository returns heterogeneous data. A repository is a collection of objects first and foremost. To use it as DAL, imkho, a bad form. We write our ReceiptStatisticCalculator, MonthOrdersReportManager, etc.

then it is difficult to name them normally, because in the subject area they do not represent anything

Talk to your economist or accountant. Helped me. Reports are well represented in the subject area.
At myself I use separate objects for reports/statistics. Simple, convenient, and always clear what it is and what to cook it with.