I have two systems (for sake of example, and orders and an account domain). Their interfaces consist of an api per system (an orders api and an account api).

I have a UI that is sitting on top of both of these services. This ui provides search functionality, which provides visibility into both domains. The problem I'm having is, how do you handle search criteria that span both domain (for example, "Get me all of the orders with a 'Pending' status associated to an account opened more than a year ago.").

The brute force method would be to query one domain, and then filtering those results with a second query to the second domain. This gets ridiculously complicated if you add in any kind of paging; if I need 500 records that satisfy the search criteria, I need to query one api, filter those results from a second query, repeat until I have 500 records.

What would be the ddd approach to this kind of cross-domain concern?

3 Answers 3


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 to try to perform realtime queries across two such distinct 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), that is optimized for specific queries. 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.

  • 1
    I am not sure if I write an answer of my own, or if your answer already covers what I have in mind. IMHO the described use case requires to build that different data store mentioned in your answer with proper indexes optimized for the expected queries. Is it that what you describe?
    – Doc Brown
    Aug 20, 2019 at 20:08
  • In this case, would it be off-base to describe this approach as essentially building a third domain (likely a very small one) that is essentially just forming projections from the order and account entities, or would it be more accurate to view it as a data-warehousing kind of responsibility? Aug 20, 2019 at 20:32
  • 1
    @DocBrown Righto, yep 👍
    – Subhash
    Aug 20, 2019 at 20:40
  • 2
    I would say it's a data-warehousing/reporting functionality. A domain would contain concepts, behaviour and invariants, and that is not the case here.
    – Subhash
    Aug 20, 2019 at 20:41

If you have a cross-service use-case then you didn't design your services right. Every use-case should go to a single service and should be fulfilled there. Otherwise you are running into not just technical problems, but dependencies. The thing that we want to fix with services in the first place.

Invoking DDD doesn't help either. Bounded context are essentially "bounded" because they are supposed to be based on completely separate vocabularies/semantics and therefore use-cases.

  • 6
    Two services can be pretty well designed at one point in time, with isolated use cases, and next year someone comes up with a new requirement which requires cross-domain access - that is how reality works. Throwing the old system away and build a new one with just one service instead of two is not even impractical, it seldom results in a better system.
    – Doc Brown
    Aug 20, 2019 at 19:56
  • 2
    Theoretically, I agree with you that having a use-case go into a single service would be ideal. I think Subhash' response arrives at an approach that could grow to provide that. For the small system I'm working on now, it essentially queries the two domains, but issues commands regarding a single domain's entities at a time. The only use-case for merging the two domains is for reporting, but in terms of the domain logic, they're very distinctive concepts that don't cross at all (there's ~100 distinct use-cases for each of the domains right now that don't cross domains). Aug 20, 2019 at 20:47

An organization sells stuff to a customer, so the DDD approach would be to have a Customer (not account) in your Orders BC. Now your query is easy.

Obviously your real problem isn’t orders and accounts/customers but in general chances are if you need to query cross BC you missed a concept in the core domain.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.