First, some background. I have an application that requires the use of several external geocoding providers which I don't control. It uses a central service layer inside the application to dispatch to the appropriate provider.
I have a number of classes that are arranged in this way:
GeocodingService: Responsible for dispatching a request to geocode something to an appropriate provider.
- Has one public method,
geocode
, that accepts a GeocodingService::Request and returns a GeocodingService::Response. - Each response includes: the latitude of the geocoded query, the longitude of the geocoded query, and a list of address components for the address where the query was found (e.g., an address component for "123", one for "Main Street", one for "Paris", and so on).
- Has one public method,
GeocodingService::AddressComponent: A single segment of an address that contains the segment's name, its abbreviation, and its kinds. For example, France has a name of
France
, an abbreviation ofFR
, and is acountry
and apolitical
segment.- AddressComponent is responsible for checking that the types an instance is set with are not outside the boundaries of certain tracked types.
Address: Domain model for addresses, containing both a preferred mailing address (a list of string lines) and a list of address components (a list of GeocodingService::AddressComponents).
My question is: where should AddressComponent live -- as a service class (like it does now), or with my other domain models?
If it lives in the service, then life is straightforward. But that seems wrong, because now a domain model has to depend on a service's definition of an address, and it seems like they should be independent.
If it lives as a full-fledged domain object, then doesn't that mean that the service is now coupled to a domain object? That also seems undesirable.
How do I resolve this impasse?