I'm curious what you recommend for handling "lists" of data, if it should be a part of the regular domain model, or some other special type of model, or something else entirely.

When I say "lists" of data, I'm referring to things that the admin end-user of the system might pick from, e.g. a list of countries, a list of currencies. Using the Agatha's storefront example, the store owner might want to specify which countries they will ship/sell to. They'll need to pick these countries from a list of all countries. Similarly, they might want to specify the currency code that indicates the currency for all their products. They'd need to pick 1 currency from a list of currencies.

How would you persist and load the list of countries and currencies, and then store the store owner's selections from that list? Another way to put would be, I want to offer the store owner some "settings" they can configure for their store, and some of these settings are restricted to pre-defined set of options (country, currency).

Does this belong in the regular domain model? Is there some other "settings" model that should be used instead?

Thanks very much!

Hi ksouthworth,

Even though countries and currencies may need to be displayed as lists they are still concerns within your domain and should be modelled as such. Even though I modelled the Country as a string property on the address, really it would have made more sense to model it as an entity or a value object, as over time it will have behaviour such as what couriers deliver to that country etc. Same with currency, at the moment in the Agathas solution I have a decimal property, but how do I know what the currency is and how on earth do I display it and format it? All of this should be behaviour within a currency value object - I think we touched on this in this post - Why is Price a "string" type in the ViewModel instead of Decimal?.

Thinking back I should have added more value objects into the Agathas solution, but to keep the page count down and because of time I dumbed it down. Value objects for things such as Money, Currency, Price, Discount etc are very, very powerful when used in a domain model, they convey the concerns of the domain better than simple types.

But to get back to your question I use a repository for Countries and Currencies.

Cheers
Scott

So you'd have repository with corresponding domain Entities for Country, Currency, etc. even though the data in those database tables isn't really going to ever change from the initial set of data? i.e. the list of countries in the world doesn't really change.

This is basically what I've done in the past as well, was just curious if there was an alternative way to do it