For our book club in Ewloe we decided for a change to watch an infoq video.
The team was showing an interest for DDD and few recent refactoring were towards encapsulation of logic in a few core Value Objects. Mike Wagg and Mark Needham suggested one of the talk they attended at QCon London 2009 Dan Bergh Johnsson value objects talk.

Discussing the talk one question came out, “When do we introduce value objects, right from the beginning or when certain conditions arise?”

The agreed answer was to introduce them later by refactoring although I now feel that we should introduce them earlier for the following reasons:

• They become useful very quickly
• They help express intent and help understand the domain
• Having few examples of Value Objects in the code base helps new developers pick up good habits because they tend to copy from existing code at the beginning

An interesting side effect of value objects… they make programmers happier! I saw smiles appear on the face of one pair of developers after they figure how value objects helped them avoid some dodgy code duplicated code in the view.

Another side effect of value objects is that they help you avoid null references by facilitating the introduction of Null Objects.

The only things that stops me to use value objects more is the friction that some tools like ORM cause. For example in order to have value objects field properly mapped using Hibernate it is necessary to implement a Custom User Type which can be an onerous an error prone operation.
There is also a lack of refactoring tools that helps you encapsulating one or more fields in a composite object.