How does the Unit of Work pattern relate to the Repository pattern, and what's the difference in what each one is responsible for?

Repository and Unit of Work are two of the most frequently confused patterns from *Patterns of Enterprise Application Architecture*, largely because popular ORMs implement both roles inside a single object, but they exist to solve genuinely different problems and are worth separating conceptually even when a specific framework merges them. ## What a Repository is responsible for A Repository's job is **retrieval**: it presents a collection-like interface — think `findById`, `findAll`, `findOverdueOrders` — for one aggregate type, hiding the actual query mechanics (SQL, an HTTP call to another service, an in-memory list in a test double) behind a domain-shaped API. From the calling code's perspective, a Repository looks like an in-memory collection you can query, even though it's backed by a database. Its scope is deliberately narrow: one Repository typically handles one aggregate root type (`CustomerRepository`, `OrderRepository`), and its methods are about reading (and, in some formulations, also adding/removing) rather than about deciding when or how changes get persisted. ## What a Unit of Work is responsible for Unit of Work's job is different: it doesn't know how to query anything, and it doesn't care what type of object it's tracking. Its entire responsibility is **bookkeeping and transaction coordination** across a business operation — remembering which objects, of any type, were created, mutated, or marked for deletion since the operation began, and, at commit time, writing all of those changes to the database as one atomic transaction in dependency-respecting order. It is, by design, agnostic to how those objects were originally found; it just needs to be told about them. | Pattern | Its job | Its scope | |---|---|---| | **Repository** | retrieval | one aggregate type | | **Unit of Work** | bookkeeping and transaction coordination | a business operation | ## How the two compose The two patterns compose naturally: 1. repositories, when asked to load an entity, register that entity with the shared Unit of Work so future mutations to it get tracked; 2. business logic then calls into several repositories over the course of one operation, mutates the objects however the business logic requires; 3. and finally calls a single `unitOfWork.commit()` rather than separately calling `save()` on each repository. This division of labor is genuinely useful even outside frameworks: it lets you unit-test business logic against fake repositories without touching a real Unit of Work, and it lets you swap out how objects are fetched without touching how changes are committed. ## The trade-off, and what ORMs actually do The trade-off with keeping them separate is the extra indirection — two abstractions and two interfaces to learn and wire together, versus one combined object. That's exactly the trade most ORMs make in the other direction: - Hibernate's `Session` and JPA's `EntityManager` act simultaneously as a query façade (you can run `session.get(...)`, `session.createQuery(...)`) and as the Unit of Work (dirty checking, identity map, flush/commit) in one object; - Spring Data's repository interfaces are typically a thin, per-aggregate-type wrapper layered on top of that same underlying `EntityManager`. In a typical Spring/Hibernate stack, then, the 'Repository' and the 'Unit of Work' end up sharing the exact same underlying persistence context, and calling `save()` through a Spring Data repository often does nothing more than register the entity with the EntityManager's Unit of Work-style tracking, rather than triggering an immediate SQL write. ## The confusion this causes in production code The common confusion this causes in production code is calling `repository.save(entity)` and assuming an immediate, isolated database write happened, when in a typical JPA-backed Spring Data repository, `save()` on an already-tracked (managed) entity is frequently a no-op from the ORM's point of view — the entity was already dirty-tracked by the Unit of Work the moment it was mutated, and the actual SQL doesn't execute until the surrounding transaction (often demarcated by a `@Transactional` method boundary, not the repository call itself) commits and the Unit of Work flushes. Developers who don't understand that `repository.save()` and the Unit of Work's commit are two different moments in time are frequently surprised by exactly when their write actually reaches the database. ## A concrete example A concrete example is a typical Spring service method: an `@Transactional` `placeOrder` method that loads a `Customer` via `customerRepository.findById(id)`, calls a `debitBalance` method on it directly, and separately calls `orderRepository.save(new Order(...))`: - the debit on the Customer is picked up purely by Unit of Work dirty checking (no explicit save call needed at all); - the new Order is explicitly registered via `save()`; - both are written to the database together only when the transactional method returns and Spring's transaction manager triggers the underlying EntityManager's commit — which is the Unit of Work's commit, wearing the Repository pattern's clothing.