Loading a Value object in List or DropdownList, DDD

I need to clarify something.

Have Person Aggreagate , 2 VOs (Country, StateProvince).

I want to load all country in my presentation layer (i am using mvc)

Evan says you only use repository (IPersonRepository) to work with root entity (it should always return just a reference to the Aggregate Root)

   public interface I开发者_JAVA百科PersonRepository()
   {
     void savePerson(Person p);
     void removePerson(Person p);
     Ilist<Person> getPerson();
   }

what i usually do to solve this :

Add in IPersonRepository this method

IList<Country> LookupCountrysOfPerson();

In Infra layer implement the Domain interfaces like this:

public IList<Person> LookupCountrysOfPerson()
{
    return Session.CreateQuery("from Countrys").List<Person>());
}

My partner says im wrong.

Sometimes you have to sacrifice your domain model in order to accomplish some task

What is the best way to do this?

with code please! :)

I would say it's unlikely that you need country to be an entity. I suspect that country is nothing more than reference data, much like a person's title would be. Is there any behavior associated to country in your domain? I suspect it's just what's printed onto letters/envelops.

This question is somewhat similar to this one which I answered a while back:

Simple aggregate root and repository question

My suggestion is that you implement a Lookup service that your client can make use of and which is cached. Ignore the rules of DDD and anything to do with aggregates or repositories for this. As someone else has mentioned, this is where CQRS's ideology comes into play; the client shouldn't have to go through the domain in order to get data. The domain is purely transactional, not designed for queries.

This article explains how to build a generic lookup service for reference data for things that typically fill dropdowns in the UI (i.e. Title, Country etc)

http://wtfperminute.blogspot.com/2011/02/working-with-reference-data-lookups.html

Evans also says (pg 170) "An entity as basic as Location may be used by many objects for many reasons..."

I would also consider making Country an entity for the reasons given above. Perhaps more importantly, it is a low level object. You probably are also even supplying Country by configuration rather than through any actual domain activities. Therefore I would remove it from the Person and make it a standalone entity.

Also for this type of object you may not really need a dedicated repository, consider creating a single lookup service that provides query access for a group of similar objects of this nature.

If in your domain country is actually a VO (you don't want to maintain a thread of identity in the country name was changed etc.) which is the most common scenario, I would add a specialized class in the data access layer to return a list of all countries as VOs. I would also add caching (2nd level cache in NHibernate) to the country entity and list all countries query so that I don't have to hit the DB each time.

Actually, this is where CQRS really shines. CQRS acknowledges that you don't have to go through the domain layer in order to get some data for presentation purposes. In CQRS you just grab some data.

It sounds like countries are not in fact value objects here; they have distinct identities and are important for business purposes outside of your Person objects. They should become entities, and be treated in the fashion appropriate to them.

Think of it this way: let's say some volatile country had their current dictator overthrown and got a name change. The Person object's reference to a Country should still be valid, because the Country is not defined by its attributes (i.e. the string denoting its name), but by its identity.