How to communicate between repositories

There is a 1-1 relation between a Repository and a AggregationRoot.

Yes

Where do I handle a query that needs data from AggregationRoot_A object and AggregationRoot_B object?

The current take on this is usually to bypass the domain model completely, and just query the database as efficiently as you can.

Recall, if you will, the early definition of aggregate (Evans, 2003)

An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.

If we aren't trying to change the data, then we don't need the "aggregate" to ensure that changes are done correctly. We just need a way to take the information currently backing the aggregates, and transform that information into the report we want.

As a matter of technique, you might create a clear boundary between the infrastructure code that is coupled tightly to your data store and the application code which should not be. Such a facade might look a little bit like an aggregate. The key distinction would be that in this case, the facade has no affordances for changing the underlying data.

In other words, this facade might superficially look like a repository, but it will be missing a few key elements -- no ability to add new objects, nothing resembling a save, and no objects that support change.

When you are performing a query, you are working with immutable values, not mutable entities.

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

Any of those can be the right answer. In situations where you are just producing a report, a web page, an html document, it will often make sense to just copy the raw data into the final representation without messing about with ceremony. Horses for courses.

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

Well, what you are really trying to get out of the pseudo-repository is an in memory data structure that you can either (a) serialize as is, or (b) transform.

If what you are doing is preparing to send that information over the wire, then you likely want as little ceremony as you can get away with - if you can transform the record set directly into your on the wire representation of the information, perfect -- trying to move the information into and out of "objects" over and over probably isn't going to make it easier for you to maintain the code over time.

When you are using that information as an input to something else, you are more likely to want to enclose the information in some implementation of a role interface, so that the consumer isn't too tightly coupled to a data structure it doesn't care about.