Should entity properties be represented by a value object?

Question

I read somewhere that one should be generous in creating value objects for entity properties that are part of the class API.

So I did that with my project entity/aggregate, but it still looks weird:

        return new Project(
                new ProjectId( $project->post->ID ),
                new DestinationNumber( $DestinationNumber ),
                new AssociatedClient( $associatedClientId ),
                new NotificationForm( $NotificationFormName ),
                new Status( $project->post->ID, $StatusFieldsAndValues ),
                new Settings( $project->post->ID, $SettingsFieldsAndValues ) 
            );

All these entity properties have getters (like getStatus), which means they are relevant for other services or repositories. So, should I make the effort to create a value object in any case, or is there a line somewhere? My example seems like overkill.

Answer 1

Should? No.

Could? Yes.

That's the short answer.

While primitive obsession is definitely something you should look into and avoid, keep in mind that anything that can be done can also be overdone.

I would argue that you can just as easily fall into the trap of "value object obsession", where you end up wrapping every single scalar value needlessly in a wrapper of its own.

Where you draw the line on reasonable value object use is very contextual, there is no universal one-size-fits-all answer here.

Answer 2

Trying to answer my own question, I would say that properties of an entity should be represented by a value object if there is any business logic attached to them, ie. a project phone number should be of a valid format, instead of just a string. Which doesn't mean that this is the only case where a value should be wrapped into an object.

Based on http://blog.ploeh.dk/2015/01/19/from-primitive-obsession-to-domain-modelling/.