Category-mistakes and Value Objects

... this article is still under construction...
first draft published Aug. 11, 2017


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. A category-mistake is a powerful concept. Ryle uses it for instance 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 great book.

I'll try to show that the sentence "Entities and Value Objects are the main elements of conventional object models"  (Evans 2004) is such a category-mistake.

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 this is not a serious example, but there is some truth in it: when designing a system DDD-practitioners often ask whether something should be modelled as an Entity or as a Value Object. You can model an appointment as being on a specific date and time, immutable, and then you'll have to schedule a new appointment if you want it on another date and time than your original one. Or you can model an appointment as something that has a date and time as attibute, that can be given another value.

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 values are referenced by objects when we define a class to designate a type for it. 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.