One data-access interface is backed by a tracking mapper in one service and an untracked layer in another; what is not interchangeable?

## What a signature carries, and what it hides An interface method that takes an identifier and returns an order looks the same whichever layer implements it. The type system describes the *shape* of what crosses the boundary and says nothing about the **lifecycle rules** attached to it — and lifecycle is exactly where a tracking mapper and an untracked layer disagree. Two implementations can satisfy the same interface, pass the same type checks, and still require callers to be written differently. ## The semantics that differ - **Whether mutation is enough.** Under a mapper, changing a returned object inside the unit of work is often sufficient: the change is detected and written. Under an untracked layer the same code is a no-op. This is the difference that produces silent data loss when an implementation is swapped. - **When the write actually lands.** One implementation sends statements at a flush it decides on; the other sends them at the call. Anything that depends on a row being visible to a second statement in the same transaction behaves differently. - **Whether the returned object is fully materialised.** A mapper may return an object with stand-ins for associations that load on access and require the unit of work to still be open. An untracked layer returns what was selected and nothing more, valid forever. Code that walks an association works under one and either fails or returns nothing under the other. - **Whether repeated reads give the same instance.** With an identity map, two reads of one row inside a unit of work tend to return the same object, so an edit through one path is visible through the other. Without one, they are two objects and the last write wins. - **Whether concurrency is checked.** Automatic version checking under one implementation, hand-written predicate and row-count inspection under the other. The interface reveals neither. | Question a caller must answer | Tracking implementation | Untracked implementation | |---|---|---| | Does mutating the result persist it? | Often yes | Never | | Is a save call required? | Sometimes optional | Always | | Is the result valid after the transaction? | Only partly | Yes | | Do two reads give one object? | Usually | No | | Is a conflicting write detected? | Often automatically | Only if you wrote the check | ## Making them genuinely interchangeable You do not make two implementations interchangeable by giving them the same types. You do it by adopting the **stricter contract on both sides** and holding the tracking implementation to it: 1. **Every change requires an explicit save call.** Mutation alone never persists, even where the mapper would have made it work. This is the one rule that removes the silent-loss class entirely. 2. **Results are fully materialised before they cross the boundary.** No stand-in may escape, so no caller can depend on a live association or an open unit of work. 3. **No caller assumes identity.** Anything that needs one instance threads it through the call chain explicitly rather than relying on the read returning the same object twice. 4. **The transaction boundary sits above the interface**, owned by one component, so neither implementation gets to decide when work is sent. 5. **The concurrency rule is part of the contract**, not of one implementation: state whether a conflicting write raises or reports, and make both implementations do that. ## What the strict contract costs It is not free, and pretending otherwise is the weak version of this answer. You give up most of what the mapper offers on the write path — automatic detection, cascade, the convenience of editing a graph and letting the flush sort it out — and you pay for the discipline with more explicit code. In return you get a boundary a reader can trust and an implementation you can actually swap, per service, without auditing every caller. There is also a testing consequence worth naming. A test suite that exercises only one implementation proves nothing about the other, because the difference lives in behaviour the interface does not express. If both implementations are genuinely in use, the same contract tests must run against both — including a test that mutates a returned object *without* saving and asserts that the row did not change. That single test is what stops a caller from quietly acquiring a dependency on write-back semantics.