Everything a Value Object in DDD

Question

I just read about Value Objects, being immutable and described as:

A small simple object, like money or a date range, whose equality isn't based on identity.

Looking at my currently existing entities I figured I could make pretty much everything that's not an entity a value object.

Let's say I have an entity class User.

class User
{
    public $id;
    public $firstname;
    public $lastname;
    public $email;
}

I could make it consist of the value objects Id, FirstName, LastName, Email and Password, because none of these User attributes equality are based on identity, right? But then again I could probably go even further and make more VOs Int, String, Name (which consists of FirstName and LastName VOs), etc.

Where do I draw he line to prevent over-engineering?

Is it normal for a domain to contain that many VOs?

Is my understanding of value objects even right?

$id may indicate that the object is not a value object but an entity where identity matters. — Joachim Isaksson, Jul 23 '14 at 09:04

guillaume31 · Accepted Answer · 2014-07-23T15:09:16.040

5

Yes, it is normal for a domain to contain lots of VO's if you want to set the bar of type safety and expressivity high enough -- which is generally a good thing.

No need to redefine Int and String, but identified ubiquitous language concepts should definitely have their own objects.

Admittedly, doing so is much more natural and painless in some languages than others. This can influence where you draw the line. In functional languages, for instance, it is not uncommon to wrap primitive types as in type UserId = UserId of int. Which I wouldn't bother doing in an OO language, class ceremony being what it is.

edited Jul 23 '14 at 15:09

answered Jul 23 '14 at 09:39

guillaume31

13,738
1
32
51

So, it would be normal for a domain to have every possible value object that's applicable in the domain? And I'm guessing those VO's can contain validation logic in them as well so that I don't have to validate them in my entities anymore, right? – Kid Diamond Jul 23 '14 at 09:47
If you're aiming at maximum type safety (not sure how it works in PHP btw), absolutely. Few VO's need validation in my experience, but it's a good idea to make your VO's immutable so you only have to validate them once at creation time. – guillaume31 Jul 23 '14 at 10:00
3

This is something that is easily refactorable though, so you can perfectly start "brainlessly" with primitive types in entities and adjust them later as you discover these smells. Domain modelling is an ever-going process, not a big bang activity. – guillaume31 Jul 23 '14 at 10:01
@guillaume31 Just making sure, but you'd have UserFirstName and UserLastName as value object ? – Ced Jul 05 '22 at 23:00

Everything a Value Object in DDD

1 Answers1