As the tech lead redesigning persistence for a system with a deep object graph - Order pointing to LineItem, LineItem to Product, Product to Supplier, Supplier to Address - some screens need only order totals while others need the full graph. How do you decide, association by association, whether to default to lazy or eager loading, and what alternative to loading full domain objects would you consider for read-heavy endpoints?

## Why one global default is the wrong frame The instinct to pick one global lazy/eager default per association and apply it everywhere is the wrong frame at this scale, because the 'right' fetch behavior is a property of a specific query and its use case, not a property of the association itself. Order-to-LineItem might be eager on an order-detail page but should stay lazy on an order-list page; Product-to-Supplier might be lazy almost everywhere except a supplier-performance report. Baking one choice into the mapping forces every consumer of that association to accept the same trade-off, which is exactly how systems end up either: - **riddled with N+1 problems** (everything defaulted to lazy, no query bothers to fetch-join what it needs), - or **chronically over-fetching** (everything defaulted to eager, so a lightweight order-list endpoint silently drags along line items, products, suppliers, and addresses it never renders). ## The default policy that scales The practical default policy that scales is: keep the mapping-level default conservative - lazy - across the board, including deep, rarely-needed hops like Product-to-Supplier and Supplier-to-Address, precisely because a conservative default fails safe (an unscoped query is merely slow to lazily fetch on demand, or throws a clear LazyInitializationException-style error outside a session, which is debuggable) rather than failing expensive silently (an eager default quietly joins in four extra tables on every single query touching Order, and nobody notices until a profiler run). Then, for every specific query/use case that does need part of the graph, explicitly widen the fetch for that one query: - a `JOIN FETCH` or entity-graph hint for order-detail pulling Order+LineItem+Product in one shot, - a batch-fetch configuration for a report that touches Supplier across many products, and so on. This turns fetch strategy into a **per-query decision** made by whoever owns that query, informed by what that specific screen or endpoint actually renders, rather than a single global guess baked into the domain model that every future consumer inherits whether it fits or not. ## Skipping the domain graph on read paths The deeper architectural move for read-heavy endpoints, though, is recognizing that loading the full domain object graph at all is often the wrong tool for a read path, regardless of how carefully lazy/eager is tuned. The domain model (Order, LineItem, Product, Supplier, Address as mapped entities with identity, associations, and behavior) exists to support writes and business logic that need that behavior - applying a discount, validating a state transition, enforcing an invariant across LineItems. A dashboard or list endpoint that only ever displays five columns has no use for that behavior; loading full entities for it means paying identity-map bookkeeping, proxy creation, and change-tracking overhead for data that will be serialized to JSON and discarded within milliseconds. A dedicated projection or DTO query - a `SELECT` that names only the columns a specific screen needs, mapped straight into a flat, non-entity read type - sidesteps N+1 concerns and eager/lazy tuning entirely, because there's no lazy association left to accidentally trigger and no unused columns being carried along. At a larger scale, this generalizes into CQRS-style separation: a distinct read model (sometimes a separate, denormalized table or materialized view, sometimes just a set of projection queries against the same schema) optimized purely for the shapes read-heavy endpoints need, decoupled from however the write-side domain model is structured for correctness. ## What the approach costs The trade-off of this approach is added surface area: instead of one canonical way to load an Order, there are now several: 1. the full entity graph for write paths and detail views, 2. several fetch-join variants for specific detail screens, 3. and one or more DTO projections for list/dashboard endpoints. That means more query code to write and keep correct as the schema evolves, and a discipline requirement (someone has to actually choose the right one per endpoint rather than defaulting to 'just load the entity, it's already there'). The cost is worth paying specifically where traffic and data volume are high enough that N+1 or over-fetching would otherwise show up as real latency or database load; for a low-traffic admin screen, loading the full lazy graph and eating an occasional extra query is often the pragmatic, lower-maintenance choice. ## What this looks like in practice A concrete, recognizable pattern for this is exactly what large e-commerce and SaaS systems do: an Order aggregate with lazy associations everywhere by default, a handful of fetch-join or entity-graph variants for the checkout/detail flows that genuinely need the nested graph, and a separate, flat order-summary projection (sometimes backed by its own denormalized table populated by domain events) powering the order-list and dashboard views that get hit far more often than the detail view ever does - the classic CQRS read-model split, motivated directly by exactly this loading-strategy trade-off rather than adopted as an abstract architectural preference.