Does it make sense to use the repository pattern with a document database?

I don't know if this will help you but I was listening to a pod-cast a while back with Ayende Rahien talking about RavenDB. He was suggesting that a document actually maps fairly well to an aggregate in the DDD philosophy. If you're using nested documents to represent an aggregate and running into design issues perhaps nesting is not the best way to go?

It's an interesting question. In my usage of MongoDB, I chose to not have a repository. This was primary because the document database was used as a read store (therefore simplifying the data that was stored there).

I guess you have to strip the consideration back to what a repository is and what advantages you get from the extra layer of abstraction. A good design will have the least number of layers possible.

A repository therefore gives you some persistence ignorance and the ability to use unit of work over a common context of data. It also can increase your ability to test queries against the data in isolation (because these are usually abstracted as queryables or specifications).

Also, some document databases already provide a repository pattern (RavenDB etc), so there is no need to have yet another layer.

So, it seems to me that using a repository is not so much about whether your data is stored as a relational table or a document, but more about what you gain from the abstraction.

Thinking about "Should I use X or not" is not as productive as focusing on "What should I use"?

What are the alternatives to the repository pattern, what are the tradeoffs, and how do they relate to your domain and implementation?

Repositories are good for enforcing a predefined set of patterns over a general-purpose store (such as SQL). For a document store, my impression is that the document schema will determine the access patterns to a greater extend than you would typically see in a SQL based store. Implementing a repository in this case may lead to very leaky abstractions, where changes to the underlying document structure have a 1:1 impact on the relevant business code. In that case the repository provides very little value. To me document stores naturally lend themselves well to Unit-of-Work (UoW) paradigms where the unit of work is a document (or doc+nested subdocs, or sets of documents).

Another strength of the repository pattern is, as you mentioned, abstraction over the storage mechanism. The tradeoff is usually loss of access to low-level implementation-specific features of Mongo. Is that a worthwhile tradeoff for you? NHibernate is very tightly coupled to SQL, and hence has richly functional abstractions over all the important features of a RDBMS. I'm not aware of any similar framework for Mongo so you would really be raising the level of abstraction quite a bit.

Do you need to support multiple concurrent data stores? For example, will you be writing some types of data to SQL and others to Mongo, through the same data layer abstraction? If so then a repository is a good option.

If you can provide some more details of your domain and implementation then we can drill down some more into the specific tradeoffs which you may want to consider