This text comes from Eric Evans’ book, Domain-Driven Design – Tackling the Complexity in the Heart of Software. It is in Chapter 6: The Life Cycle of a Domain Object.
A Factory handles the beginning of an object’s life; a Repository helps manage the middle and the end. When objects are being held in memory, or stored in an object database, this is straightforward. But typically there is at least some object storage in relational databases, files, or other, non-object-oriented systems. In such cases, the retrieved data must be reconstituted into object form.
Because the Repository is, in this case, creating objects based on data, many people consider the Repository to be a Factory – indeed it is, from a technical point of view. But it is more useful to keep the model in the forefront and as mentioned before, the reconstitution of a stored obect is not the creation of a new conceptual object. In this domain-driven view of the design, Factories and Repositories have distinct responsibilities. The Factory makes new objects; The Repository finds old objects. The client of a repository should be given the illusion that the objects are in memory. The object may have to be reconstituted (yes, a new instance may be created), but it is the same conceptual object, still in the middle of its life cycle.
One other case that drives people to combine FACTORY and REPOSITORY is the the desire for “find or create” functionality, in which a client can describe an object it wants, and if no such object is found, will be given a newly created one. This function should be avoided. It is a minor convenience at best. A lot of cases in which it seems useful go away when ENTITIES and VALUE OBJECTS are distinguished. A client that wants a VALUE OBJECT can go straight to a FACTORY and ask for a new one. Usually, the distinction between a new object and an existing object is important in the domain, and a framework that transparently combine them will actually muddle the situation.
The Repository Pattern