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.

The InvestmentFund class looks a bit like the following but 10 times larger:

I am trying to push the use of more granular and less primitive objects in our domain and I am promoting a refactoring of our core domain objects by following three ways suggested in the book Growing Object Oriented Software Guided by Tests:

• Breaking out consists in splitting the responsibilities of large objects in several smaller ones.
• Budding off is used to mark domain concepts in code by creating objects that wrap fields or not fields at all.
• Bundling up consists in assembling in one object a group of values that are generally used together.

A first refactoring bundled up together some of the values of InvestmentFund like the fees information. The result was a type Fee:

which transformed our InvestmentFund class in:

A second refactoring that I would like to pursue is a way to differentiate decimals that represent money and decimals that represent percentages. Budding off those type make sense but I am not sure of the best to model rates.
Do I need a general Percentage type, a more specific InterestRate type or a type for each one of my rate types like “commission”?
The latter looks a bit like what my collegue Mark Needham describes as a Micro-Type.

I will probably start with the simplest solution (a Percentage type) and see how it goes.

Feedback is much appreciated.