Category-mistakes and Value Objects

Practicioners of Domain Driven Design (DDD) often ask whether something should be modelled as an Entity or as a Value Object. An Entity is a domain-object with an identity-property, so it can change over time and still be tracked. It can also be discerned from similar objects by its identity, even if they have the same state. On the other hand, a Value Object is an immutable object without an identity-property. Two Value Objects with the same state, the same value, are considered replacable, interchangeable, effectively the same. Although the distinction between Entities and Value objects has many merits, it is a so called category-mistake to use the two conjunctive or disjunctive in one sentence. A category-mistake is not a term from category theory, but coined by the linguistic philosopher Gilbert Ryle in the middle of the 20th century.


An example: someone is visiting Oxford or Cambridge. After having seen a number of colleges, libraries, playing fields, museums, scientific departments and administrative offices the visitor asks: "I've seen all those buildings, but where is the University?" Another illustration: someone watching a cricket game learns what the functions of the bowlers, the batsmen, the fielders, the umpires and the scorers are. He then says "But there is no one left on the field to contribute the famous element of team-spirit". These are some of the examples used by Gilbert Ryle in his book 'The Concept of Mind', first published in 1949, to explain what category-mistakes are. Ryle uses the concept of a category-mistake to show that the sentence "there exist both bodies and minds" (a.k.a. Descartes' Myth) is absurd.

Ryle: "When two terms belong to the same category, it is proper to construct conjunctive propositions embodying them. Thus a purchaser may say that he bought a left-hand glove and a right-hand glove, but not that he bought a left-hand glove, a right-hand glove and a pair of gloves." You'll find more examples and analyses in Ryle's book. BTW: it's one of the best books I ever read, highly recommended.

Value objects

 I phoned my dentist to change an appointment. "Sorry, we cannot do that", the assistant replied. "Why?", I asked."Because we have a new software system, entirely made with DDD. Appointments are now Value Objects and so they are immutable". Of course I'm just joking, but there is some truth in it: in DDD you can often hear that some date and time should be modeled as an (immutable) Value Object.  You then model an appointment as being on a specific date and time, immutable, and you'll have to reschedule a new appointment if you want it on another date and time.

In essence the date and time are values of the appointment. In our traditional class oriented languages dates and times are objects and all objects are assigned by reference, not by value. And there you have the core of the problem: changing the value of an object means changing any reference to that object. As with many design patterns the solution is specific to the used language and paradigm. For instance: most Gang of Four design patterns are not needed when working in pure functional languages. They offer solutions for specific problems of class oriented languages. The same holds for the design patern of Value Objects: it is a solution for the problem that when we define a class to designate a type for values, in many computer languages the value is stored as a reference to an object. In languages where we can define types without defining a class for it, like in many functional languages, we don't have this problem.

Value objects are just values, values of properties of  (domain) objects. The confusing part is that in many traditional languages those values are molded into objects, mostly because an extensible type-system is missing. Those "objects" can be seen as a poor man's (M/F) solution for types. You sometimes hear the term "value types" to express this idea.

Entities and Value Objects: different categories

An object can have properties with values. Values can be of a specific type (which can be built as an object, but that is not important here). Objects are not of the same category as their properties. It is for instance absurd to say: "in my garage I have my (red) car AND the colour red". Because "red" is just the value of the  colour-property of the car-object and even if that property is instantiated as a (value) object, the car and its colour are still of a different category.

The merits of Value Objects

In 2004, at the time Evans and Fowler wrote about the Value Object Design Pattern, two "solutions" were very much used where a Value Object would  have been a better choice: "Primitive Obsession" and "Entititis". "Primitive Obsession" is where a standard type is used, that is built in into the used computer language, like String or Integer. "Entititis" is making everything entities; often easily made possible by standard libraries and ORM frameworks. Object orientation was the main paradigm and there were not many possibilities for custom typing other than via object instantiation in the mainstream languages of that moment. So, it came at the right time and we can still learn a lot from the warnings against both "Primitive Obsession" and "Entititis". And because many of the current used computer languages are still mainly using their classes and objects to define custom types, the idea of Value Objects is still useful.

Better models by avoiding category-mistakes

Category-mistakes give fuzzy terms. Being aware of their existence can make your model more clear, more precise.

(I'm woking on the finishing touches of this article; August 20, 2017).

Herman Peeren
August 2017