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.
views:
778answers:
4You'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.
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.
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.