+1  A: 

The state and county are not entities, but value objects. They are not the subject of your system. The way you said you treated these previously is OK. When will you change the state or county records in your database, based on the changes in the state of your domain model? Not, so these will not need a repository.

OK, That makes some sense. What threw me off somewhat was the fact that I am interested in the ID field of the objects, but that doesn't necessarily make them "entities", does it. Where do you put the creation of all the value objects go? Into a global ValueObjectFactory class? Is there a best practice?
John
+1  A: 

You're reading the wrong book if you want to learn how to do DDD without over complicating it. :-)

The simplest solution you're proposing is fine if it meets your needs. Encapsulating address data in business objects can be as simple or as complicated as your application demands. For example, the State object has a one-to-many relationship with County so Employee really just needs to reference a County if you chose to model it that way. I would only introduce that sort of complexity if required.

Additionally, I don't think there's much to be gained by defining interfaces for your repositories unless there's a real possibility that you might have multiple repositories for your objects.

Jamie Ide
My understanding is that you're not really doing DDD if you're not using interfaces for your repositories. And doesn't creating an interface for your repository more easily enable you to do mocks? Regardless, in Visual Studio it takes all of 1 second to generate an interface from a class you designed, so I don't really see a downside to using interface. Thanks.
John
What's the point of an interface if you only have one class that implements it? Concrete classes are just as mockable as interfaces. I do think that interfaces are valuable for services classes that may have more than one implementation and if you're using a dependency injection framework.
Jamie Ide
I would also argue that extracting an interface from a class is a backward approach -- the contract should be designed before the implementation. Done this way, interfaces do have an advantage for unit testing because tests can created using mocked interfaces before any concrete implementations are coded.
Jamie Ide
OK, it looks like I was mixing up Palermo's "Onion" framework, which does require interfaces for the repositories, with DDD. Also, every example that I come across so far showsg DDD repositories using interfaces, but that's probably a SOLID thing, not a DDD thing. Actually, what I do is create the class and stubs in Visual Studio's class designer, extract an interface and afterwards write the code. So I do agree -- interface before implementation. Thanks.
John
The point of having an interface for that only class is to be able to test it. You can then stub it, mock it ... eat it if you like ...I agree with john ... you are doing well ... go ahead
jalchr
+1  A: 

Using DDD I have something similar with the following:

interface IAddressService
{
  IList<Country> GetCountries ();
  IList<State> GetStatesByCountry (string country);
  IList<City> GetCitiesByState (string state);
  // snip
}

Country, State and City are value objects which come from a lookup table in the database.

Todd Smith
+1  A: 

You may want to look into the concept of Command Query Separation. I wouldn't worry about typed repositories for lookup values, but I'd still probably use DTO type classes over datasets etc...

You may want to spend some time reading Greg Young's blogs starting from this one to the present. He doesn't talk about filling lookup data specifically but he often talks about not handling the reading/reporting functionality of your application through typed methods on a repository.

Daniel Auger
Thanks. I'm not sure that it's an exact answer, but it gets me on the right track which is "what's the best way to retrieve read-only data".
John