A generic Repository<T, ID> interface with methods like findById, findAll(Specification spec), and save(T entity) is shared as a base type across a dozen unrelated entity types in a large system. What failure modes tend to show up as the system grows, and how do teams typically evolve away from it?

## Why a generic base looks attractive A generic `Repository<T, ID>` interface — declaring `findById(id: ID): T?`, `findAll(spec: Specification<T>): List<T>`, `save(entity: T): T`, `delete(id: ID)` — is an attractive starting point in a growing codebase because it lets every entity type get CRUD support for free, with **zero repeated boilerplate**: `class CustomerRepository : Repository<Customer, Long>`, `class OrderRepository : Repository<Order, Long>`, and so on, each inheriting the same generic operations. This is essentially what frameworks like Spring Data JPA formalize and generate automatically via `JpaRepository<T, ID>`, and for a meaningful stretch of a system's growth it works well precisely because most entities really do share the same basic shape of persistence need early on. ## The failure modes The failure modes emerge specifically from **heterogeneity** that develops as the system matures and entities stop being uniform in their persistence needs. 1. **First, consistency and invalidation requirements diverge**: some entities are simple value-holders where 'save the whole object' is perfectly fine, while others are complex aggregates where saving 'the whole object' through a generic `save()` risks silently persisting a partially-invalid intermediate state, or bypassing invariants that should only be checked by an aggregate-specific save path (this overlaps with, but is distinct from, full DDD aggregate-repository semantics, which govern which objects even get their own repository in the first place). A generic `save(T)` signature has no way to express 'this type has extra invariants that must hold before persisting' — that logic either gets duplicated in every caller, or silently omitted somewhere, which is how production bugs slip through: an entity gets saved in an invalid intermediate state because the generic path offered no natural place to intercept and validate. 2. **Second, the generic querying mechanism** — typically a `Specification<T>` or `Criteria<T>` object parameterized over the shared base type — tends to become a lowest-common-denominator API that mirrors whatever the underlying query engine can express generically (equality, ranges, basic joins), rather than the richer, more specific query vocabulary any one entity's real use cases need. Teams often find themselves either fighting the generic Specification API to express an entity-specific query it wasn't really designed for, or falling back to a non-generic escape hatch (a raw `@Query` or hand-written method) anyway, at which point the generic abstraction has stopped pulling its weight for that entity while still imposing its shape everywhere else. 3. **Third, and often the most consequential in retrospect**: a single generic Repository base makes it easy to accidentally treat every entity as independently saveable and independently queryable, when in a well-modeled domain only some objects (aggregate roots) should really have their own Repository at all — child entities that only make sense in the context of a parent aggregate shouldn't be independently loadable and saveable through their own generic Repository, because that invites callers to load and mutate a child object without going through the aggregate root that's supposed to enforce invariants across the whole aggregate. A flat, generic `Repository<T, ID>` applied uniformly doesn't naturally surface this distinction; it takes deliberate modeling discipline (or a design review) to notice that `OrderLineItem` shouldn't have its own top-level Repository the way `Order` does. ## How teams evolve away from it As these failure modes accumulate, the typical evolution is a **narrowing rather than an abandonment**. - The generic base gets replaced, entity by entity, with a purpose-built Repository interface exposing intention-revealing, entity-specific methods (`findOrdersAwaitingFulfillment()`, `reserveInventoryFor(orderId)`-style operations that may not even look like traditional CRUD), while a genuinely universal concern — e.g., `findById` — may survive as a thin, optional shared building block rather than the entire interface's shape. - Some teams keep a generic base purely at the *implementation* level (a shared internal helper for boilerplate CRUD wiring) while making the *public* interface each aggregate exposes entirely bespoke, which captures the original convenience (less repeated plumbing code) without forcing every caller through a one-size-fits-all contract. ## A real-world instance A concrete, well-known real-world instance of this exact tension: Spring Data JPA's `JpaRepository<T, ID>` is, functionally, precisely this generic base, and a huge number of production Spring codebases start by extending it directly for every entity. Teams commonly report exactly the trajectory described above as their domain model matures — introducing entity-specific `@Query` methods and `Specification` composition as needs diverge, and, in domain-heavy modules, eventually wrapping or replacing the generic `JpaRepository` extension with a hand-written, framework-agnostic interface exposing only the operations that specific aggregate's business logic actually needs, precisely to stop child entities and simple value objects from acquiring their own independently-callable generic repository the way the true aggregate roots do.