So why not just implement something similar to the following example, avoiding the need for a new Value Object class altogether?
class Product
{
private id;
private name;
/**
* @var int
*/
private $amount;
/**
* @var string
*/
private $currency;
// ...
}
This approach has some noticeable flaws, if say, for example, you want to validate the ISO. It doesn't really make sense for the Product to be responsible for the Currency's ISO validation (thus violating the Single Responsibility Principle). This is highlighted even more so if you want to reuse the accompanying logic in other parts of your Domain (to abide by the DRY principle).
With these factors in mind, this use case is a perfect candidate for being abstracted out into a Value Object. Using this abstraction not only gives you the opportunity to group related properties together, but it also allows you to create higher-order concepts and a more concrete Ubiquitous Language.
Discuss with a peer whether or not an email could be considered a Value Object. Does the context it's used in matter?