DDD, Repositories and ORMs

One of the confusing aspects of those new to DDD is the concept of a Repository.  From Fowler’s Patterns of Enterprise Application Architecture, a Repository:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

Paraphrasing the various DDD sources, a Repository provides the ability to obtain a reference to an Aggregate root.  Not Entity, Value Object, but Aggregate root.  Each Save operation encapsulates the entire operation for saving a single Root and all of its child entities.  For example, given the model of a Root Person entity with child Address entities, a Save operation will save Person and Address, all in one operation, from the perspective of the client of the Repository.

From the client perspective, how an object is persisted is unimportant.  From the developer perspective, persistence is very important!  Many who follow DDD choose to use various ORMs to provide the persistence logic inside the Repository.

Because DDD does not prescribe a persistence technology, nor even a storage medium, using an ORM like NHibernate does not indicate you doing DDD.  Conversely, doing DDD does not predestine you into an ORM technology like NHibernate.  I could use the Cargo Cult metaphor, were it not for the Cargo Cult of folks using the Cargo Cult metaphor.

You can do DDD with stored procedures.  You can create Repositories for in-memory databases, all the LINQ implementations (including EF).  A Repository is a pattern, not a technology prescription.  It’s far more important to learn the concepts than jump to a technology, that’s the short bath to a bad experience.