I am curious how others would handle this situation. I have a domain layer that includes an Address object. I then have an application that uses this object. Additionally, there is an asp.net asmx web service that performs address validation by going out to a third party web service.
I am curious how to deal with this functionality. I don’t want to put the service reference and code to access the web service in the domain layer. It also seems wrong to put it in the application layer.
My current best solution is to create a third assembly that references the original domain layer AND the validation web service. This keeps my domain layer a bit cleaner with no external references. How would you handle this situation?
Well, is validating the address part of the application (UI) logic or part of your domain requirements?
If it’s an app function, it goes in the app layer. If it’s a core domain function, it goes in the domain layer.
If you’re concerned about coupling – for example, if you think that you might decide to use a different address validation service in the future – then place an abstraction over it. Create an interface and a wrapper class:
Or whatever the logic is. Then make your application (or domain model) depend on
IAddressValidatorinstead of the service itself, and fan in a concreteIAddressValidatorinstance from the outermost layer.You could put the core
IAddressValidatorinterface in your domain model and keep theFooAddressValidatorin an external assembly that’s only ever referenced by the executable. That way your domain isn’t actually dependent on the web service, but you still have address validation as part of your domain logic.This also makes whatever uses the address validation component a lot easier to test, since you don’t actually need to make web service calls, you can use a different
MockAddressValidatorinstance for that.