I have some entities and some value objects that need to record the moment they were made. Now I read that a value object is a collection of properties with its own set of rules, and two value objects with the same properties are indistinguishable.
Now, I'm probably going to use the standard C# DateTime data type for this, and I don't really know how it is implemented internally (might just be a Unix timestamp, which as a primitive should be a property, but if they have a solution to the year 2038 issue that involves multiple properties in some relation with each other, it would be more complicated).
I think that what makes the difference is that although a timestamp has its own set of rules (e.g. "35th of January" is no valid date), I am not going to be enforcing those rules; the language itself will. The date is always created internally; I'm never parsing anything user-submitted into a date.
So I am leaning towards a timestamp being a property. But then I started thinking: can I apply that rule to any data type which has its rules defined outside my application? For example, an image file. I am not in charge of having it be structured correctly according to the JPEG specification; the language will do that. I could have restrictions on file size, but similarly an entity could have restrictions on the length of one of its strings and I don't see that being made into a value object for just that reason, though I could be wrong on that.
And what if there is a bespoke set of rules for a data type, e.g. an invoice, that the company I work with already implemented elsewhere and I am importing as a library? That could be as complicated a data type as it gets.
- Is a timestamp a value object or a property of one?
- What makes the difference between value objects and properties? Is it a locally defined set of rules, or is it something else?
And even more concretely; I am choosing between these two models (which I understand are to correspond more or less directly with my actual code):