DDD how to handle value objects without repository - domain-driven-design

Question

I need some help with a value object. Consider the following example.
I have entity Card which has pan currency(USD, EUR, GBP) and card type (Visa, Visa Electron, Mastercard). I think currencies and card types are value objects and they are stored in the source code. According to DDD value objects don't have repositories.
The question is how to fill the dropdowns of currencies and a card
types in the interface when creating new Card entity.
Where to put that classes in Application, Domain or Infrastructure layer
and how to retrieve data from them.
A simple example would be priceless"
UPDATE1
That was my first approach but..
I use currencies in other entities like MoneyTransfer there i use EUR USD GBP and a few more so i have to create one more enum
public enum MoneyTransferCurrency{
USD, EUR, GBP and a few other
}
This way i duplicate some currencies and if we stop processing payments in USD i have to find all enums and delete the USD currency.

Answer 1

Don't try to make simple things complicated.
If you know a-priori all the possible values of these VO, you can have them as enum.
public enum Currency{
USD, EUR, GBP
}
And then from the code:
Currency.values()
Ask yourself, how often these values changes? (how often a new kind of currency is used by the system?)
Is the cost of developing and maintaining a system (like db tables) to add remove these values dynamically without restart the application less than using an enum and recompile the project when there is a change?
A lot of times I was critizied for this solution with arguments like "I need a description of the value", like in a view writing "Euro" when you have the EUR value, if you have a table you can have a description column.
This can be easily solved using a properties file like:
labels.currency.EUR=Euro
labels.currency.USD=Dollars
Check also this:
- Loading a Value object in List or DropdownList, DDD
- Simple aggregate root and repository question

Answer 2

You misunderstood VOs, read some more info about them, i think easy way to understand them is to look up Person / Addres example.
What about your case, just create 3 tables, don't try to make simple things complicated:
Card (CardID, CurrencyID, CardTypeID)
Currency (CurrencyID, CurrencyName)
CardType (CardTypeID, CardTypeName)
For DropDowns you will just query Currency & CardType tables. And in future if you will add new Currency or CardType it will be easy to do.

Answer 3

Currency and CardType aren't necessarily sensible value objects. Value objects model a conceptual whole containing related attributes. Value objects can be compared by comparing all of their attributes.
Think for example of an MonetaryValue value object that consists of a numerical value together with a currency:
public class MonetaryValue {
private BigDecimal value;
private Currency currency;
public Amount(BigDecimal value, Currency currency) {
// validations:
assertNotNull(value);
assertNotNull(currency);
this.value = value;
this.currency = currency;
}
[...]
}
Value (e.g. 100) and currency (e.g. eur) together describe the worth of a thing. The thing isn't worth just "100" and not just "eur", but "100 eur".
Comparing of value objects is also important. When talking about monetary values, both attributes, value and currency, need to be compared. Comparing the value without the currency wouldn't help much, since 100 usd isn't the same as 100 eur. This is a further indication that MonetaryValue could be a sensible value object.