Identity map pattern¶

A unit-of-work cache that guarantees one in-memory object instance per persistent database identity within a declared context.

Version: v2 · 2026-09-19 · History
Domain-specific #: 4957
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Enterprise Software → Computer Science & Software Engineering

Core Idea¶

An identity map keys loaded objects by persistent identifier and returns the existing instance on repeat retrieval, preventing duplicate representations and inconsistent updates during one session or transaction. A repository consults the map before loading, registers newly materialized objects under their identity and clears or scopes the map at a defined lifecycle boundary. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

How would you explain it like I'm…

No Twin Toys List

Imagine a helper who fetches toys from a big storage room. The helper keeps a list of every toy already brought out. If you ask for the same toy again, the helper hands you the one you already have, not a second copy. That way you never end up with two teddies that are really the same teddy.

One Record, One Object

Computer programs often load information from a database, like a customer record. An identity map is a list that remembers every record already loaded, using each record's ID number. Before loading something, the program checks the list first. If the record is already there, it hands back the exact same one. This stops the program from having two copies that disagree when one gets changed. The list is cleared when a work session ends.

Same-Instance Lookup Map

The identity map pattern is a software design technique for programs that load objects from a database. It keeps a map from each object's persistent identifier (its database ID) to the in-memory object already created for it. When the program asks for an object, the repository checks the map before going to the database. If the object is present, the program gets back that same instance; if not, it loads the object and registers it in the map. This guarantees one in-memory representation per stored record within a session or transaction. That prevents duplicate copies and conflicting updates. The map is scoped to a defined lifetime, such as one session, and cleared at its end. This is different from a plain cache, whose main goal is speed rather than the same-instance guarantee.

The identity map pattern keys loaded objects by their persistent identifier and returns the existing instance on repeat retrieval, preventing duplicate representations and inconsistent updates within one session or transaction. A repository consults the map before hitting the data store, registers newly materialized objects under their identity, and clears or scopes the map at a defined lifecycle boundary. To claim the pattern is present, several things must be explicit: the persistence identity and object type, the map key, the session or unit-of-work scope, the lookup-before-load rule, when registration happens, the concurrency and invalidation policy, and the same-instance guarantee. If any of these is missing or a neighboring idea like a generic cache is substituted, the pattern isn't genuinely there. Once established, you can rely on reference equality meaning record equality within the scope. It does not promise anything beyond that scope.

Scope of Application¶

Identity map pattern belongs to enterprise software and is useful where the analyst can specify the typed enterprise software carrier, including its objects, relations, parameters, conventions, evidence, boundary cases, and comparison targets, then evaluate the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee are explicit. The scope is broad within that domain but bounded by the need for the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee are explicit. The entry records a descriptive analytical identity; practical use requires the governing domain's evidence, standards, and safety obligations.

Clarity¶

The abstraction clarifies a crowded vocabulary by making the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee are explicit the center of the account. A claim should name the carrier, the governing operation or relation, the applicable assumptions, and the recognition test. A bare label is insufficient because the name Identity map pattern can be used for a formal identity, an implementation, or a neighboring result unless carrier and convention are stated.

Manages Complexity¶

Without the abstraction, an analyst must reason directly over many local details: the carrier roles, admissibility assumptions, competing conventions, derived invariants, boundary cases, and proof or validation obligations specific to Identity map pattern. Identity map pattern compresses them into the roles in the structural signature. That compression permits comparison across instances without erasing the variables that determine validity. It also exposes which details may be varied safely and which are constitutive.

Abstract Reasoning¶

Identify the carrier. State what the elements, states, objects, or observations are: the typed enterprise software carrier, including its objects, relations, parameters, conventions, evidence, boundary cases, and comparison targets. Reject examples whose alleged carrier belongs to a different problem.
Lock the constitutive rule. Express the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee are explicit independently of one notation or implementation.

Knowledge Transfer¶

Knowledge transfers strongly among subfields of enterprise software because they reuse the typed enterprise software carrier, including its objects, relations, parameters, conventions, evidence, boundary cases, and comparison targets, A repository consults the map before loading, registers newly materialized objects under their identity and clears or scopes the map at a defined lifecycle boundary., and type the carrier, state every parameter and convention in the definition, test that the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee are explicit, compare the nearest accepted identity, and report counterexamples, uncertainty, and limiting cases.

Relationships to Other Abstractions¶

Current abstraction Identity map pattern Domain-specific

Parents (1) — outgoing typed relations

Identity map pattern is a kind of Caching Prime

It remains its own entry because its identity is fixed by the persistence identity and object type, map key, session or unit-of-work scope, lookup-before-load rule, registration timing, concurrency and invalidation policy and same-instance guarantee.

Hierarchy paths (9) — routes to 7 parentless roots

Identity map pattern → is a kind of Caching → presupposes Locality Of Reference → is a kind of Recurrence

Show alternative paths (8)

Neighborhood in Abstraction Space¶

Identity map pattern sits in a crowded region of the domain-specific corpus (20^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software Architecture & Modeling Methods (23 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25