0

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.

4
  • I haven't seen anything like that before. Is it possible you misunderstood what you read "somewhere?" That said, having six new keywords in the same place is not exactly unprecedented; the problem here is that you need to have a good understanding of why. Aug 18, 2018 at 22:20
  • Make $project->post->ID be an instance of ProjectId instead of a primitive, then you have one less thing to new here. Aug 19, 2018 at 16:34
  • I probably misunderstood the concept, since I'm just getting into the whole idea of entities and value objects. From the book: "In DDD, types like that [string, DateTimeImmutable, UuidInterface] are usually avoided in the domain and are replaced by value objects. That approach [...] adds a lot of meaning to the code. You don't have to wrap every single value into a value object, but the public API of your domain objects should use them generously."
    – Hans
    Aug 19, 2018 at 19:07
  • 1
    Similar: Value Objects, when to create one/
    – Mike
    Aug 29, 2018 at 14:30

2 Answers 2

3

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.

4
  • I'd suggest maybe rather than no for Should?
    – jk.
    Aug 19, 2020 at 10:42
  • @jk. You've fallen prey to a logical fallacy (1) "Could" = optional = maybe (2) "Should" = required = must. (3) The logical opposite of "should" (i.e. the "no") means "you're not required to", it does not mean "you're not allowed to" (4) The inverse of "could" (i.e. a "no") means "you are not allowed/able to".
    – Flater
    Aug 19, 2020 at 10:45
  • Depends on the context. RFC 2119 (quite often used for technical documents) specifies different meaning, so does my native (Czech) language, where meanings of "should" and "must" greatly differentiate, while you mention them to be equal.
    – Andy
    Aug 19, 2020 at 10:53
  • @Andy: AH, the "joys" of humans and their vague semantics :) Strictly logically, "should not" means "not required", but you are indeed correct that humans often infer this to mean "not allowed" or "not advised", e.g. "you should not eat that poisonous berry". But I do think that in the context of comparing "should? no. could? yes", it's clear that I'm sticking to the logical expression, not the semantically vauge one.
    – Flater
    Aug 19, 2020 at 10:57
1

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/.

9
  • Just so I understand where you're going with this, can you tell me what you think "value object" means? Aug 29, 2018 at 14:46
  • A value (and it's invariants) that is represented by an object.
    – Hans
    Aug 29, 2018 at 15:21
  • 2
    Ok. Well, I looked up "Value Object" on Wikipedia, and it says that a Value Object is an object having value semantics for equality; that is, if I compare two such objects for equality, the result of that comparison is based on the value of the object, and not the reference to that object. Fowler agrees with this definition. In languages like C# and Java, you can make any object a "value object" by implementing an "equatable" or "comparable" interface. Aug 29, 2018 at 15:30
  • 1
    Seeman's article is interesting, and it does provide some insight into where one might choose to put their business logic, but I don't see how that has much to do with something being a "value object." Aug 29, 2018 at 15:31
  • 2
    When two reference variables are compared for equality in C# or Java, the references to the two objects are compared. Essentially, the two variables must be pointing to the same object. If you're comparing two strings for equality, this is almost certainly not what you want, which is why C# automatically confers value semantics on strings. Seeman is mostly discussing checking the validity of a string, e.g. a telephone number or social security number. Making a telephone number an actual object allows you to encapsulate the validation rules for a telephone number inside that object. Aug 29, 2018 at 15:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.