When to use Whole Value

[jupitermoon_beam]

I love the whole value pattern and try and use it where I can (plug:
http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html).

My question is how far should the exercise of Whole Value go? Objects
like PostCode or TelephoneNumber are obvious but what about the
simpler things like Title, Surname or Forename?

On the surface is looks like Title, Surname and Forename can exist
happily as strings but you often find that you're soon adding
Surname.IsDoubleBarelled or Title.IsMilitary or Forename.IsSimilarTo
(a real method I've seen for matching duplicate customers e.g. Geoff
and Jeff).

My question is how aggresively do people use the Whole Value pattern
in their domains? On one side of the corner is the argument that any
concept should be abstracted and encapsulated on the other side is are
you wasting your time?

[Joe A. Reddy]

Practically speaking I think I follow the ol' I'll do it when I need it
rule.

For example, Title is a string until it needs behavior like answering
the question "Is Military?"



I don't think it is black and white. Doing it all the time could sure be
overkill and a pain, especially in the more unstable early iterations of
your application. However, it is a real shame if we ignore the benefits,
or are just ignorant of those benefits, or are ignorant of recognizing a
situation that could benefit from this design.



-Joe







-----Original Message-----
From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of
jupitermoon_beam
Sent: Thursday, April 12, 2007 10:40 AM
To: ***@yahoogroups.com
Subject: [domaindrivendesign] When to use Whole Value



I love the whole value pattern and try and use it where I can (plug:
http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html
<http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html> ).

My question is how far should the exercise of Whole Value go? Objects
like PostCode or TelephoneNumber are obvious but what about the
simpler things like Title, Surname or Forename?

On the surface is looks like Title, Surname and Forename can exist
happily as strings but you often find that you're soon adding
Surname.IsDoubleBarelled or Title.IsMilitary or Forename.IsSimilarTo
(a real method I've seen for matching duplicate customers e.g. Geoff
and Jeff).

My question is how aggresively do people use the Whole Value pattern
in their domains? On one side of the corner is the argument that any
concept should be abstracted and encapsulated on the other side is are
you wasting your time?

[jupitermoon_beam]

Post by Joe A. Reddy
Practically speaking I think I follow the ol' I'll do it when I need

it rule.

YAGNI is certainly where I try to stand on this but what's interesting
is I find that over time most concepts very easily end up as Whole
Values. Also I think YAGNI can be a bit grey here because this can be
more about good vs bad practice.

Post by Joe A. Reddy
Doing it all the time could sure be overkill and a pain

Interestingly the reason it is a pain isn't to do with the concept
being a bad practice. It would be very hard to argue why a domain
concept (such as forename) shouldn't become a Whole Value apart from
the fact there is a programming overhead (I'm sure someone passionate
enough could give many very sound reasons). If languages made it as
easy to create Whole Values as creating Classes then we wouldn't be
worried about overkill. Personally I use code generation solutions to
create the WVs meaning the overhead in creation is quite low (though
not as low as typing string). Doing it early can sometimes reduce
maintanance as refactoring Name from a string can mean going through
and replacing a lot of the basic string validation code through the
domain.

Post by Joe A. Reddy
recognizing a situation that could benefit from this design.

Things like PostCode and TelephoneNumber are obvious because they do
have composite parts which make a whole (they aren't just strings).
Things like names are tricky but even then as a domain progresses
concepts (especially validation and cleaning) sneak in and the best
place for them is within the WV.

As I said above that the only critisism of being too purist with WV is
that you may just be creating extra work for yourself but it isn't a
"bad thing" and in some respects is more OOP (imagine how nice it
would be working in a domain with 100% of all concepts modelled into
objects).

By the way I'm just playing devil's advocate here I'm not nessasarily
arguing that every concept should be an object (for the reasons
already given) I'm just interested to find out if overhead is the only
reason and if there are any specific technical reasons why it could be
a "bad thing".

Post by Joe A. Reddy
Practically speaking I think I follow the ol' I'll do it when I need it
rule.
For example, Title is a string until it needs behavior like answering
the question "Is Military?"
I don't think it is black and white. Doing it all the time could sure be
overkill and a pain, especially in the more unstable early iterations of
your application. However, it is a real shame if we ignore the benefits,
or are just ignorant of those benefits, or are ignorant of recognizing a
situation that could benefit from this design.
-Joe
-----Original Message-----
jupitermoon_beam
Sent: Thursday, April 12, 2007 10:40 AM
Subject: [domaindrivendesign] When to use Whole Value
http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html
<http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html> ).
My question is how far should the exercise of Whole Value go? Objects
like PostCode or TelephoneNumber are obvious but what about the
simpler things like Title, Surname or Forename?
On the surface is looks like Title, Surname and Forename can exist
happily as strings but you often find that you're soon adding
Surname.IsDoubleBarelled or Title.IsMilitary or Forename.IsSimilarTo
(a real method I've seen for matching duplicate customers e.g. Geoff
and Jeff).
My question is how aggresively do people use the Whole Value pattern
in their domains? On one side of the corner is the argument that any
concept should be abstracted and encapsulated on the other side is are
you wasting your time?

[Joe A. Reddy]

I agree with everything you are saying. Its one of those things that
feels like overhead, like overkill and it eats at your gut. But I don't
think you can come up with any strong argument against it. Hell, opening
up a code generator and typing "Surname" and "string" then clicking a
button is almost more work than just typing out the code yourself. ;-)





-----Original Message-----
From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of
jupitermoon_beam
Sent: Friday, April 13, 2007 4:14 AM
To: ***@yahoogroups.com
Subject: [domaindrivendesign] Re: When to use Whole Value

Post by Joe A. Reddy
Practically speaking I think I follow the ol' I'll do it when I need

it rule.

YAGNI is certainly where I try to stand on this but what's interesting
is I find that over time most concepts very easily end up as Whole
Values. Also I think YAGNI can be a bit grey here because this can be
more about good vs bad practice.

Post by Joe A. Reddy
Doing it all the time could sure be overkill and a pain

Interestingly the reason it is a pain isn't to do with the concept
being a bad practice. It would be very hard to argue why a domain
concept (such as forename) shouldn't become a Whole Value apart from
the fact there is a programming overhead (I'm sure someone passionate
enough could give many very sound reasons). If languages made it as
easy to create Whole Values as creating Classes then we wouldn't be
worried about overkill. Personally I use code generation solutions to
create the WVs meaning the overhead in creation is quite low (though
not as low as typing string). Doing it early can sometimes reduce
maintanance as refactoring Name from a string can mean going through
and replacing a lot of the basic string validation code through the
domain.

Post by Joe A. Reddy
recognizing a situation that could benefit from this design.

Things like PostCode and TelephoneNumber are obvious because they do
have composite parts which make a whole (they aren't just strings).
Things like names are tricky but even then as a domain progresses
concepts (especially validation and cleaning) sneak in and the best
place for them is within the WV.

As I said above that the only critisism of being too purist with WV is
that you may just be creating extra work for yourself but it isn't a
"bad thing" and in some respects is more OOP (imagine how nice it
would be working in a domain with 100% of all concepts modelled into
objects).

By the way I'm just playing devil's advocate here I'm not nessasarily
arguing that every concept should be an object (for the reasons
already given) I'm just interested to find out if overhead is the only
reason and if there are any specific technical reasons why it could be
a "bad thing".

--- In ***@yahoogroups.com
<mailto:domaindrivendesign%40yahoogroups.com> , "Joe A. Reddy"

Post by Joe A. Reddy
Practically speaking I think I follow the ol' I'll do it when I need it
rule.
For example, Title is a string until it needs behavior like answering
the question "Is Military?"
I don't think it is black and white. Doing it all the time could sure be
overkill and a pain, especially in the more unstable early iterations of
your application. However, it is a real shame if we ignore the

benefits,

Post by Joe A. Reddy
or are just ignorant of those benefits, or are ignorant of recognizing a
situation that could benefit from this design.
-Joe
-----Original Message-----

<mailto:domaindrivendesign%40yahoogroups.com>
<mailto:domaindrivendesign%40yahoogroups.com> ] On Behalf Of

Post by Joe A. Reddy
jupitermoon_beam
Sent: Thursday, April 12, 2007 10:40 AM

<mailto:domaindrivendesign%40yahoogroups.com>

Post by Joe A. Reddy
Subject: [domaindrivendesign] When to use Whole Value
http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html

<http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html>

Post by Joe A. Reddy
<http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html

<http://jupitermoonbeam.blogspot.com/2007/04/whole-values.html> > ).

Post by Joe A. Reddy
My question is how far should the exercise of Whole Value go? Objects
like PostCode or TelephoneNumber are obvious but what about the
simpler things like Title, Surname or Forename?
On the surface is looks like Title, Surname and Forename can exist
happily as strings but you often find that you're soon adding
Surname.IsDoubleBarelled or Title.IsMilitary or Forename.IsSimilarTo
(a real method I've seen for matching duplicate customers e.g. Geoff
and Jeff).
My question is how aggresively do people use the Whole Value pattern
in their domains? On one side of the corner is the argument that any
concept should be abstracted and encapsulated on the other side is are
you wasting your time?