Beside using the handful of literal values offered by the language (numbers, strings, true and false), and an even smaller complement of objects normally used as values (date, time, point), you will make and use new objects that represent the meaningful quantities of your business. These values (values like currency, calendar period or telephone number) will carry whole, useful chunks of information from the user-interface to the domain model.
When parameterizing or otherwise quantifying a business (domain) model there remains an overwhelming desire to express these parameters in the most fundamental units of computation. Not only is this no longer necessary (it was standard practice in languages with weak or no abstraction), it actually interferes with smooth and proper communication between the parts of your program and with its users. Because bits, strings and numbers can be used to represent almost anything, any one in isolation means almost nothing.
Therefore:
Construct specialized values to quantify your domain model and use these values as the arguments of their messages and as the units of input and output. Make sure these objects capture the whole quantity with all its implications beyond merely magnitude, but, keep them independent of any particular domain. (The word value here implies that these objects do not have an identity of importance.) Include format converters in your user-interface (or better yet, in your field and cell widgets) that can correctly and reliably construct these objects on input and print them on output. Do not expect your domain model to handle string or numeric representations of the same information. Consider:
the message: contractDurationInDays answers: 21 the message: contractDurationInDaysAsString answers: '21'
Both of these messages use wordy protocol and answer quantities devoid of meaning once returned. The following simpler message returns a whole value with meaning in isolation.
the message: contractDuration answers: Weeks(3)
You will find that these objects will capture some of the irregularity and (possibly) ambiguity of the domain model.
Expect particular classes to grow into hierarchies over time. But, do not extend whole values to include non-applicable or exceptional quantities better represented by an Exceptional Value.
Avoid undue reasoning regarding inappropriate combinations of values so long as lower level checks will insure Meaningless Behavior will eventually result.
DOT FROM preview-next-diagram