I am going to assume that we don't have to debate the need for two systems (orders and accounts) and you have a real need for them to be so.
It's a good analogy to consider each domain to be a separate microservice, that are running on different machines and ports, and are scaled differently. Then the requirement becomes clearer.
It is a bad idea even to try to do realtime queries across two such systems.
In the past when I have encountered such cases, I have gone with background processes that prepare and populate the required data into a different data store (either a separate table in the same database or even a different database like ElasticSearch that excels at searching). And your requirement does sound like a Reporting use case.
I also usually make use of CQRS principles coupled with Domain Events to create the background processes, for the sake of architectural clarity and performance. This Query-oriented approach results in well-defined, separate, read-only data stores.
But a word of caution related to my first assumption. You need to check if you need two separate domains for your concepts in the first place. Treating them so will introduce complexity and additional work for collating data from both, so you need to be really sure about getting into it.