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:
- Does the above
ConsentSearchDTO
make sense? - 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.