Seperating assemblies with web references

Question

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?

Answer 1

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:

public interface IAddressValidator
{
    bool ValidateAddress(Address address);
}

public class FooAddressValidator : IAddressValidator
{
    private FooService service;

    public FooAddressValidator(FooService service)
    {
        this.service = service;
    }

    public bool ValidateAddress(Address address)
    {
        return service.ValidateAddress(address.StreetLine1, address.City,
            address.State, address.Country);
    }
}

Or whatever the logic is. Then make your application (or domain model) depend on IAddressValidator instead of the service itself, and fan in a concrete IAddressValidator instance from the outermost layer.

You could put the core IAddressValidator interface in your domain model and keep the FooAddressValidator in 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 MockAddressValidator instance for that.