I was thinking about some entities I need, when I came across a very interesting concept: Immutable Objects.
The Immutable Objects are very handy to manage the so called Value Objects.
In the Domain Driven Design (DDD) properties of an
Entity can have two different values: other Entities (
Order->getProduct() – here
Product is an
Entity and its properties can change) or simple values (
Price, in our example, is a simple value, not conceptually an
Entity. Until now, it probably is a simple property in your Entities (as it was in mine!).
But, in this second case, the Value Objects play their parts: they represent those values in an immutable state.
In fact, if you reflect about the data
Price , you realize that a
Price is something like “100 Eur”. If you put your attention on the value, you can recognize more than one smaller parts in it: a numeric value – 100 – and a string value – Eur.
Price is a
Price only if we indicate both the numeric part of it (100) and the string part of it (Eur): If we indicate only one of the two, it is not a
Price because we don’t know how much money does it represents or in which currency the price is expressed.
So we need both the “amount” and the “currency” to have a real value. Think it as a “composite value”.
And the important thing to consider to understand what Immutable stands for: if in the
Price we change the amount, we have a different price. If in the
Price we change the currency, we have, again, a different price.
But if in a
Product we change the
Price, we don’t have a different
Product but the same one with only a different