In a system with both a rich write-side aggregate repository and heavy reporting/read needs, how do you decide the boundary between what stays on the aggregate repository versus what moves to a separate read model, and what keeps that boundary from eroding as the system grows?

## Two different jobs The boundary between an aggregate's repository and a separate read model is fundamentally a boundary between two different jobs: **protecting invariants during state changes**, versus **answering questions about state**. - An **aggregate repository** exists to load a whole, invariant-consistent aggregate so that domain logic can be invoked on it and the result saved atomically — that's expensive by design, because consistency is expensive by design. - A **read model** exists purely to answer questions — filter this, sort that, sum this — and has no obligation to load anything resembling a full aggregate, enforce any invariant, or even represent data in the same shape the write side uses internally. ## The decision rule is behavioral, not structural The decision rule that keeps this boundary sharp is behavioral, not structural: ask whether the calling code, after getting data back, - needs to invoke a domain method that could fail an invariant check (in which case it needs a real aggregate from the repository), - or whether it only ever reads the data to display, export, filter, or aggregate it (in which case a read model, decoupled from the aggregate's shape and cost, is the right tool). This test generalizes well because it doesn't depend on how 'complex' the query looks — a single-field lookup used to drive a domain decision belongs on the repository; a ten-column joined report used only for display belongs on the read side. ## How much divergence is worth building Once the boundary is drawn, the practical question is how much divergence between write and read representations is worth building. | Read side | What it is | What comes with it | |---|---|---| | At the cheap end | a read model can be nothing more than a set of hand-written SQL query classes or views reading the same tables the write-side repository uses, returning DTOs instead of aggregates | no additional infrastructure, no synchronization lag, just a second, honestly-named access path that isn't pretending to respect the aggregate abstraction | | At the expensive end | a full CQRS read side maintains a separately-optimized, potentially separately-stored representation (denormalized tables, a search index, a different database engine entirely) kept in sync via domain events | accepting eventual consistency between write and read in exchange for read performance and shape that can diverge arbitrarily from the aggregate's internal structure | The trade-off scales with the gap: the further reporting needs get from 'the aggregate's own shape, just read-only', the more a separate materialized representation earns its keep, but every step toward full CQRS adds - synchronization machinery, - a new class of bugs (a read model out of sync with the write model, for a window of time or, if the sync pipeline breaks, indefinitely), - and operational surface (another store, another migration path, another thing that pages someone at 3am). ## What keeps the boundary from eroding What actually keeps the boundary from eroding, in practice, has less to do with the initial design decision and everything to do with **team governance over time**, because the pressure to blur the line is constant and individually always looks reasonable: a query is urgently needed, adding one more finder method to the existing, familiar aggregate repository interface feels faster than standing up a new read-model class, and it usually is faster in the moment. Left unmanaged, this produces exactly the accumulation described as a failure mode elsewhere in this topic — a repository interface that's technically still 'per aggregate' but has quietly become a general-purpose query surface with dozens of narrowly-specific methods that map to UI filters rather than domain concepts. The countermeasure that works is: 1. treating any addition to the aggregate repository's interface as something a code review should explicitly ask 'does this need a real aggregate to invoke behavior on, or does it just need data' about, rather than nodding it through because it superficially matches the existing method style; 2. and periodically (not just reactively) auditing repository interfaces for methods that no longer serve a domain-behavior caller, migrating those to the read side as a scheduled cleanup rather than leaving the interface to keep growing indefinitely. ## A governance example A concrete governance example: a logistics platform's `ShipmentRepository` originally had a clean four-method interface (`findById`, `add`, `findPendingPickups`, `findByTrackingNumber`) that mapped directly to real domain workflows. Over eighteen months, seven more finder methods were added, each individually justified by a real feature request, until an architecture review discovered that five of the new seven were only ever called by controller code building JSON responses for a customer-facing tracking page — none of them ever invoked a domain method on the returned `Shipment`. The team's fix wasn't a rewrite; it was extracting those five into a `ShipmentTrackingQueries` read-model class backed by the same tables (no new infrastructure needed, since the divergence from the write shape was small), leaving `ShipmentRepository` back down to methods that genuine domain workflows use, and adding a lightweight review checklist item — 'does this repository method's caller invoke domain behavior on the result?' — specifically to catch the next drift before it accumulated to the same degree again.