0

Where do you like to draw the line for modeling a single value as a Value Object v.s. a primitive? For example if I have an internal order number and a customer order number, would you model them both as Value Objects even if they only contain a single string attribute and no special validation? I see the benefit it adds for type safety and readability, but how much is too much? At what point is a primitive ok? I'm starting to find that in my current project I am modeling everything as a Value Object and it's starting to feel bloated.

Thanks for any feedback in advance!

secondbreakfast
  • 237
  • 1
  • 8
  • What benefits of type safety and readability do you get from value objects that you don't equally get from entity objects? Reference – Robert Harvey Sep 16 '21 at 21:58
  • Note that, in some programming languages, you can get value type equality semantics for entities by implementing interfaces such as IEquatable. – Robert Harvey Sep 16 '21 at 22:00
  • 1
    @RobertHarvey my dilemma isn't between Value Objects and Entities, it's between Value Objects and primitive types. – secondbreakfast Sep 16 '21 at 22:22
  • It’s good practice to model all properties of entities as value objects. You say some have no validation, but it’s more likely you haven’t discovered that yet. What do you mean when you say it feels bloated? – Rik D Sep 16 '21 at 22:42
  • @RikD I'm ending up with like 30 extra classes that could easily be modeled as primitives without anything really changing – secondbreakfast Sep 17 '21 at 00:49
  • OK, I'll rephrase the question. What benefits do you feel you're getting from value objects that you don't already get from primitive types? – Robert Harvey Sep 17 '21 at 01:43
  • 1
    @RobertHarvey 1. Type safety. createOrder(InternalOrderNumber internalOrderNumber, CustomerOrderNumber customerOrderNumber) v.s. the alternative createOrder(String internalOrderNumber, String customerOrderNumber), which would allow any type of String, perhaps even accidentally passing variables in the wrong order. 2. Readability. To me, seeing code like List<PhoneNumber> phoneNumbers looks a lot better than List<String> phoneNumbers. This could also help when developers choose poor variable names. 3. Searchability. Want to see all uses of PhoneNumber? Easy. With a String? Good luck. – secondbreakfast Sep 17 '21 at 02:05
  • 3
    Seems like you've answered your own question. Are you willing to give up those benefits for the feeling of less bloat? – casablanca Sep 17 '21 at 03:04
  • @casablanca insert old man Captain America meme "No, I don't think I will" – secondbreakfast Sep 17 '21 at 04:19
  • 2
    @zero01alpha: Right. So now your decision comes down to a value judgement: Are the benefits worth the additional costs? (hint: they might be.) There are "traditional" solutions for most of these problems, of course; validation prevents most argument problems, higher order functions or IComparable implementations solve the searching and sorting problems, and most developers worth their salt understand how a string works. At the end of the day, it's always a value judgement; there's seldom a clear-cut case of right or wrong. – Robert Harvey Sep 17 '21 at 12:55

0 Answers0