Standard value types as ValueObjects in DDD?

Question

When modeling a domain with entities and value objects, would it make any sense to also make "basic" value types as well defined value objects?

For instance, I can have a value object EmailAddress or ProductName. But what about just String as a value object? Is it against any known principle for any good reason? What I really is wondering is if I should/could define all possible property values as value objects, including string, bool, int etc. Is that wrong or just doing it to far? Somehow I feel I would prefer really being explicit with any "thing" that is a value of some sort and not leave anything open to interpretation. What do you think? What does the gurus say about this?

---

A reference I stumbled on:

It's often a good idea to replace common primitives, such as strings, with appropriate value objects. While I can represent a telephone number as a string, turning into a telephone number object makes variables and parameters more explicit (with type checking when the language supports it), a natural focus for validation, and avoiding inapplicable behaviors (such as doing arithmetic on integer id numbers).

Answer 1

Value objects in DDD are a great thing, they are immutable so they are safe for passing around, they encompass the data and its behaviour in a nice OOP mode (if you use OOP). They also make the implicit explicit and provide strong typing.

If you need any of the above features then you should create a Value object (class, component... whatever exist in your language) for any property that needs it.

If however, you don't need any of the above then you should not do it. You don't create a new Class only because some "guru" says so, for example that every property of an Aggregate should be a Value object.

The most important aspect, is that if you have some property that has data and also behavior and you need to make a Class for it then that class should be a Value object, in special, it should be immutable (Entities excluded).

Answer 2

You probably need to read the "Out of the tar pit" whitepaper or watch the talk by Romeu Moura at DDD Norway meetup.

Primitive types are not helping to make implicit explicit. They are implicit by default. This makes the system indefinitely complex since the number of states of such system is indefinite.

I agree that classes might feel like a burden. You might indeed avoid using value objects but then you need to accept that your Ubiquitous Language is not ubiquitous anymore. Ubiquitous means that the language is used everywhere, including the code. You cannot say "product name" to the domain expect and then get back to your code and see "string". This does not convey your domain language to other developers too.

Yves Reinhout delivered the great talk about these things at last year's KanDDDinsly conference, recommended to watch.

I personally really expect new OO language features like the proposed C# record types, to make things just as easy as in functional languages. By the way, reading about type system in functional language provides many great insights for OO programmers too. For example, F# for Fun and Profit has this great article about types and DDD. By the way, it starts by looking string, what a coincidence...