This is one of the most important aspects to grasp. Object values shouldn't be able to be altered over their lifetime. Because of this immutability, Value Objects are easy to reason and test and are free of undesired/unexpected side effects. As such, Value Objects should be created through their constructors. In order to build one, you usually pass the required primitive types or other Value Objects through this constructor.

Value Objects are always in a valid state; that's why we create them in a single atomic step. Empty constructors with multiple setters and getters move the creation responsibility to the client, resulting in the Anemic Domain Model, which is considered an anti-pattern.

It's also good to point out that it's not recommended to hold references to Entities in your Value Objects. Entities are mutable, and holding references to them could lead to undesirable side effects occurring in the Value Object.

In languages with method overloading, such as Java, you can create multiple constructors with the same name. Each of these constructors are provided with different options to build the same type of resulting object. In PHP, we're able to provide a similar capability by way of factory methods. These specific factory methods are also known as semantic constructors. The main goal of fromMoney is to provide more contextual meaning than the plain constructor. More radical approaches propose to make the __construct method private and build every instance using a semantic constructor.

In our Money object, we could add some useful factory methods like the following:

class Money 
{ 
    // ...
    public static function fromMoney(Money $aMoney)
    {
        return new self(
            $aMoney->amount(),
            $aMoney->currency()
        );
    }

    public static function ofCurrency(Currency $aCurrency)
    {
        return new self(0, $aCurrency);
    }
}

By using the self keyword, we don't couple the code with the class name. As such, a change to the class name or namespace won't affect these factory methods. This small implementation detail helps when refactoring the code at a later date.

Due to this immutability, we must consider how to handle mutable actions that are common place in a stateful context. If we require a state change, we now have to return a brand new Value Object representation with this change. If we want to increase the amount of, for example, a Money Value Object, we're required to instead return a new Money instance with the desired modifications.

Fortunately, it's relatively simple to abide by this rule, as shown in the example below:

class Money 
{ 
   // ...
    public function increaseAmountBy($anAmount)
    {
        return new self(
            $this->amount() + $anAmount,
            $this->currency()
        );
    }
}

The Money object returned by increaseAmountBy is different from the Money client object that received the method call. This can be observed in the example comparability checks below:

$aMoney = new Money(100, new Currency('USD')); 
$otherMoney = $aMoney->increaseAmountBy(100);

var_dump($aMoney === otherMoney); // bool(false)

$aMoney = $aMoney->increaseAmountBy(100); 
var_dump($aMoney === $otherMoney); // bool(false)