Some languages give certain types no stable reference identity at all: structs are copied on assignment, or values are moved. How do you model an entity whose identity must persist in such a language, and what changes once the entity crosses a process or storage boundary?

## Three identities, only one portable Separate three questions that are easy to conflate. **Address identity**: do these two expressions denote the same storage right now, in this process? **Value equality**: is the content equivalent? **Domain identity**: do these two representations stand for the same thing in the world, an order, a user, a device? Only domain identity is a property of the model. The other two are properties of a runtime, and both evaporate the moment a value is copied, moved, serialized, cached in another process or reconstructed from a database row. ## Languages that hand out address identity for free Java, C#, Python, Ruby and JavaScript give every object a distinguishable reference. Because it is free, it gets used unintentionally: a set of objects deduplicates by reference until someone defines otherwise, and two loads of the same database row produce two members. Even where it exists it is narrower than people assume. CPython's `id()` is an address that is reused after the object is collected, so two objects with equal ids can exist at different times in one run. On a compacting collector the address itself moves, which is why identity hash values are stored rather than derived from location. ## Languages where it is absent or deliberately withheld **Go**: assignment copies a struct. After `b := a` there are two independent values, and `==` on comparable structs compares field by field, so two genuinely different entities that happen to share field values compare equal, while one entity held in two variables occupies two addresses. Neither address nor structural comparison answers "same entity?", so idiomatic Go carries an ID field and compares that. **Swift**: `===` is defined for class references only. Structs have value semantics and no identity operator, so the choice between `struct` and `class` at declaration time *is* the choice between value and entity. Few languages force the modeller to make that call explicitly; Swift's guidance to prefer structs unless you need identity is exactly this distinction stated as a rule. **Rust**: values move, the compiler may relocate them, and there is no universal identity accessor. Comparing shared ownership requires `Rc::ptr_eq`, which you can only call if you already chose a shared pointer type. Identity is opt-in and visible in the type signature rather than ambient. **C and C++**: an object has an address while it lives, but copies, moves and reallocation invalidate any assumption that the address is the thing. A `std::vector` reallocation relocates every element. ## Modelling identity when the language will not The answer is the same everywhere and is the reason it is worth learning: **reify identity as data**. Give the entity a key: a natural key drawn from the domain (ISBN, IATA code) or a surrogate one (UUID, ULID, database sequence). Compare entities by that key alone, and compare values by content. This yields three concrete rules. First, an entity's equality must not depend on mutable content, or the same entity stops equalling itself after an edit. Second, a value type's equality must not depend on a key, or two equal values become distinct for no domain reason. Third, an entity with no key yet assigned has no stable identity, which is the classic transient-instance trap: Hibernate, EF Core and SQLAlchemy all let you place an unsaved object into a hash-based set before the key exists, after which assigning the key silently changes what the object claims to be. The standard mitigations are to assign identity client-side (UUID at construction, so it exists before persistence) or to keep unsaved entities out of key-based containers entirely. ## The boundary Once an entity crosses a boundary, address identity is simply not in the payload. Serialization writes fields; the receiver reconstructs a new object. This is why every mature ORM maintains an **identity map**: within one session, one row maps to one object, so reference comparison happens to work; across sessions it does not, and code that relied on reference comparison breaks in exactly the situation you cannot test locally. It is also why distributed systems generate identity that is meaningful without coordination, UUIDv4, UUIDv7 or ULID for time-ordered locality, rather than relying on a central sequence. A single systems note, worth one sentence: content-addressed stores invert the relation deliberately, deriving identity from a hash of the value, which is sound only because the value is immutable, and which by design makes two independently produced identical values the same entity. ## The judgement calls Deciding entity versus value is the primary modelling act, and languages differ in whether they make you state it. A money amount, a coordinate and a date range are values: equal content means equal, and copying is harmless. A user, an order and a device are entities: they have a life, they change, and two snapshots at different times are the same thing. Getting this wrong is expensive in both directions, an entity treated as a value silently merges distinct records during deduplication, and a value treated as an entity fragments caches and prevents sharing. Ask, for each type, "if every field changed, would this still be the same thing?" A yes means you need a key, and the key must be data.