it's a value! it's a reference!

[John Rose]

Thanks, Michael, for the reference (not reference*) to what looks like a very thoughtful and useful body of work. 

The idea that identity is linked to a “thread of continuity” is spot on. I would also call that a “continuous chain of custody”. Or just unbroken data flow. 

What value* classes do that’s different is to provide a potential way (besides a continuous chain of custody) to create a second reference to a value* object that is the same* as a first value* object, without needing a reference to the first.

More details, again using the starred provisional terms value*, reference*, same*, that relate to the above:

It’s as if the reference* object were supplied with an identity token at birth, unique in all of history, which never gets lots. Kind of like the little wristband a baby gets (hat tip to Brian for that metaphor).  Two reference* objects are not the same* if they have different “wristbands”, even if their classes and state components match perfectly, even if they have no state at all, as with “new Object()”, which is just a skinny guy with a wristband. 

This, you can forge a perfect copy of the first value* object if you know only its components.

Reference* objects cannot be forged from their components; they are never the same* thing twice. (Because each gets a fresh identity.) This is necessary, of course, in order for them to keep track of mutable state, when they have it.

If you define aliasing in terms of same*-ness, it follows that value* objects are easier to alias because they are easier to forge from components. (There is no identity to spoil the task.) But aliasing of value* objects is harmless, compared to aliasing of mutable reference* objects, so we don’t even pay attention to it. 

> On Feb 24, 2019, at 1:04 AM, Michael van Acken <michael.van.acken at gmail.com> wrote:
> 
> Note: In the context of DDD, "identity" usually refers to a property
> of a real world "object", modeled in software for example as an
> attribute "customerID" of a class "Customer".  Eric Evans has more
> on this in his DDD book (89pp "Entities (a.k.a Reference Objects)").