One of the main rules of DDD is that value objects are immutable. This is often not as self-evident as it seems, as many programmers are not even aware of the state they leak and create. Sadly, state is often positively correlated with entropy. Hence, taking steps to contain and to limit state is one of the keys to taming complexity in an application.

He notes that even outside of DDD Value Objects can be quite useful. He gives an example of a "RationalNumber" class with methods for basic things like addition and subtraction. He shows the more traditional mutable version that most developers would start with and uses it in several examples to show its flaws. He finishes up the post with a look at the "more correct" immutable version of the class and a sample call that would result in the correct output of a simple matematical operation.

Yesterday I tweeted: Modern object-oriented programming languages need support for immutable Value Objects. #DDD The "DDD" in that tweet stands for Domain-Driven Design. There were several interesting responses to this tweet.

Responses to his tweet included comments from Matthew Weier O'Phinney, Ralph Schindler, Nicolas Berard-Nault and Giorgio Sironi. He notes that, while all of the suggestions are good, they're only half of the issue. They make it immutable when defined but not during execution. Currently PHP lacks this functionality, but something like this could be worked in with the concept of a "final" class.