Value Object Lists in Distributed Domain Driven Design

I need some tangible guidance on implementing list of value objects in my distributed DDD application. Here's what I have:

My application is based on a RESTful service application running on a server providing services to several client applications. One of my entities, Customer, has a Region property that contains a reference to one of many Region value types. The list of Regions is stored in the back-end database but we do NOT provide an interface to maintain this list. Any changes will be made directly in the database (since it will be so infrequent) and will most likely be name changes and not add/removes. On occassion, like expansion into a new market, a new item could be added, thus the requirement for the list to be 'dynamic'.

When editing a Customer record in one of the client UIs, I need to display the list of Regions in a drop-down list with the selected item associated with the Customer domain object's Region property.

I can handle the UI side of it but am fuzzy how the list of Regions should be obtained and maintained in my domain layer. Do I have a separate RegionRepository or should the list be retrieved from the CustomerRespository? What if Customer was the only entity that referenced the Value Object? If multiple entities referenced the VO, would that change the approach?

I actually have many of thes开发者_如何学Ce types of lookups and don't want to create a separate repository (and web service) for each unless it's recommended. I've thought about a single Lookup service for the API, but hesitate to implement until I have a better grasp of the impact this route will have.

While the list items are 'keyed', they don't fit the definition of an entity with their own identity and they don't exist except in the context of the parent domain object (in this case, Customer). So I'm assuming they are Value Objects, which is fine. But, again, I am unclear how I should structure my app to allow clients to retrieve the list of VOs for a scenario like what I described above.

You can place them anywhere that makes sense. Where you choose to expose the property and implement the repository isn't going to break any covenant of DDD.

As an example I use the following:

interface IAddress
{
    List<State> GetStatesByCountry (string country);
}

and I also have

interface ITaxes
{
    List<State> GetStates ();
}

In my case both of these get implemented by an ILookupRepository simply because that's how that particular backend system is designed. Yet in another one of our systems we have an actual ICountryRepository because both the backend and services are different from the above system and it makes more sense for that scenario.

I found the key to this problem was taking a step back and assessing what context the lookup list actually exists. For instance, a list of Regions may be sales territories, geographical regions, etc. Identifying this has typically led me to another context object with the list existing as a child.