TLDR; I have a neat domain model that makes it easy to communicate with an external web service. New requirements have made the external web service’s interface messy and now I have to gather data from multiple places in my model. Is a DTO appropriate to hold all the necessary data?

I have an interface that deals with searching for some domain models. The concrete implementation behind it goes to an external web service for results.

interface IConsentSearch    // only one method  +Search(Customer) : IList<Consent>  class Customer  +various properties 

My domain model is, of course, much more complex, but this is the gist of it.

Now, I got some new requirements that would allow us to search by order id in addition to the Customer‘s properties. In my internal domain model, orderId has its own little place somewhere (not part of Customer). The problem is that the external web service interface has a completely different idea of where orderId is.

Note: it is not an either/or situation: everything Customer has to offer is mandatory for the search to take place – order id is just an additional criteria.

I am going to have to change Search() signature and thought of creating a new DTO in my application service layer called ConsentSearchDTO. New DTO would serve one purpose: to combine data and models that are now scattered throughout my domain model and necessary for querying the external web service:

interface IConsentSearch    // still only one method  +Search(ConsentSearchDTO) : IList<Consent>  class Customer      // still the same  +various properties  class ConsentSearchDTO  +Customer : Customer  +OrderId : int 

My questions:

1. Does the above ConsentSearchDTO make sense?
2. Is it ok to create a DTO that references domain model classes (Customer) or should I create a whole new structure that mimics the original domain model? This seems like a lot of work and doesn’t bring me any additional value.