The project I’m working on at the moment spins around one main domain concept. For the sake of the example I would use a class InvestmentFund.
The initial approach to the design of the InvestmentFund object was quite rudimentary but unfortunately something not uncommon in our industry.
Each field of the database table got mapped to a field in the object and there is an abundance of primitive and nullable fields.

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.