What does 'persistence ignorance' mean for a domain model accessed through repositories, and what specific repository design choices support it or quietly undermine it?

## What persistence ignorance means **Persistence ignorance** is the design property that a domain model's classes are written purely in terms of the business problem they model, with no knowledge of — and no compromises made for — how instances of those classes get saved to or loaded from durable storage. A persistence-ignorant `Order` class has fields and methods that reflect what an order is and does in the business (line items, a total, a status, methods like `cancel()` or `applyDiscount()`), and nothing that reflects how it's stored: - no `@Entity` or `@Table` annotations, - no required no-argument constructor added solely so a framework can instantiate it via reflection, - no public setters added solely so a mapper can populate private fields, - no base class inherited from an ORM framework. The **repository is the mechanism that makes this possible**: it is the seam at which the domain model's shape and the storage's shape are reconciled, and that reconciliation work — object-relational mapping, key generation, dirty-checking, lazy-loading strategy — lives entirely in the repository's infrastructure-layer implementation, never in the domain class itself. ## Why the property exists Persistence ignorance exists to solve a specific, recurring problem: persistence-technology concerns are notoriously invasive, and left unchecked they reshape domain models around the technology's needs rather than the business's needs. A domain model designed 'ORM-first' tends to end up with - public setters on every field (because the ORM needs to populate them), - collections exposed as mutable lists (because the ORM's lazy-loading proxies need a concrete collection type to wrap), - and behavior-free getter/setter classes because business logic doesn't fit comfortably alongside framework-managed state. The **anemic domain model** anti-pattern is very often downstream of persistence technology leaking into the model. Persistence ignorance, enforced at the repository boundary, keeps the domain model designed around invariants and behavior first, with the mapping problem solved separately and invisibly to domain code. ## The trade-off The trade-off is **real effort moved, not effort eliminated**. Someone still has to write the mapping between a rich domain object (with private fields, no-setter immutable value objects, and business-rule-enforcing constructors) and a persisted representation (rows, columns, foreign keys, or a JSON document). Without an ORM's convention-based mapping (which itself typically demands framework-friendly classes), that mapping is often hand-written: - constructing an `Order` from a result set by calling its real constructor, - reading private state through a documented reconstruction path, - and translating change events back to SQL. This is more code, and more code to maintain, than letting an ORM manage the domain classes directly — the cost of persistence ignorance is paid in repository-implementation complexity, in exchange for a domain model that stays clean, testable without a database, and free to evolve its internal shape without a migration-adjacent conversation about framework constraints. ## Failure modes Failure modes show up as small compromises that compound. 1. **A no-arg constructor** added 'just so the ORM can instantiate it' looks harmless in isolation but means the class can now be constructed in an invalid state anywhere in the codebase, not just inside the repository — the domain model's own invariant-enforcing constructor is no longer the only way to get an instance. 2. **Public setters** added for hydration mean any code, not just the repository, can mutate state that was supposed to be changed only through domain methods that maintain invariants — `order.setStatus(SHIPPED)` bypasses whatever business rule `order.ship()` was supposed to check. 3. **Returning the ORM's own managed/proxied entity type** directly from a repository method (instead of mapping it to a plain domain object) means callers now depend on that entity staying attached to a live persistence session; calling a lazily-loaded getter after the session closes throws a lazy-initialization error at runtime, in code that has no idea it's touching persistence machinery at all. Each of these compromises is individually small, which is exactly why they accumulate — a team rationalizes 'just this one setter' repeatedly until the domain model is, functionally, an ORM entity with some methods bolted on. ## A concrete example A concrete example: a banking `Account` aggregate has a private `balanceMinor: Long` field, no public setter, and a `withdraw(amount: Money)` method that throws if the withdrawal would violate a minimum-balance invariant. **AccountRepository's** infrastructure implementation reconstructs `Account` instances from database rows by calling a package-private or reflection-based reconstruction path specifically reserved for persistence — never the same constructor application code uses to open a new account — and, on save, computes the diff needed to update the balance column rather than exposing a setter that any caller could invoke. The domain module has zero references to the ORM's annotations or interfaces; if the team later swaps the ORM (or drops it for hand-written SQL), only the `AccountRepository` implementation changes — the `Account` class, and every domain/application-service test written against it, is untouched.