repository-persistence

What problem does it solve?

It prevents persistence-layer details (ORM objects, query builders, lazy-loading behavior, and raw storage exceptions) from leaking into your domain and application logic, keeping your models stable while your database technology changes.

Core Features & Use Cases

• Repository boundary discipline: define repository interfaces in domain/application language and keep storage mechanics behind the implementation.
• No ORM leakage rules: ensure repository inputs/outputs are domain objects or plain DTOs, not ORM entities, proxies, or query-builder types.
• Explicit semantics for correctness: document not-found outcomes (missing vs soft-deleted/filtered), query contracts (pagination, ordering, consistency), and transaction participation (ambient vs caller-provided vs new transactions).
• Error translation: map storage exceptions (e.g., unique constraint violations) into domain/application-meaningful outcomes instead of propagating raw ORM/database errors.
• Use Case: you add a new repository method for an aggregate root but need consistent not-found behavior, pagination guarantees, and reliable transactional participation across multiple repository calls.

Quick Start

Use repository-persistence when you need to redesign or document a repository contract so it clearly defines mapping, not-found behavior, transaction scope, query semantics, and error translation without exposing ORM details.