Repository ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung. Es dient als Schnittstelle zwischen der Domänenschicht und der Datenzugriffsschicht. Es ist insbesondere in den Situationen hilfreich, in denen es viele unterschiedliche Domänenklassen oder viele unterschiedliche Zugriffe auf die Datenzugriffsschicht gibt.

Konzeptionell kapselt das Repository die durch die Datenzugriffsschicht persistierten Objekte und den Zugriff auf sie – unabhängig davon, ob diese in einer Datenbank gespeichert, oder über einen Webservice (oder anderweitig) zur Verfügung gestellt werden. Damit wird ein objektorientierter Zugriff auf die Datenzugriffsschicht und somit eine klare Trennung und gerichtete Abhängigkeit zwischen der Domänenschicht und der Datenzugriffsschicht erreicht.

Gegenüber der Domänenschicht verhält sich das Repository wie eine Liste von Fachobjekten. Fachobjekte können wie bei einer im Speicher befindlichen Liste hinzugefügt oder entfernt werden, das Repository kümmert sich um das Mapping und den Aufruf der entsprechenden Operationen der Datenzugriffsschicht. Darüber hinaus können mittels deklarativer Suchabfragen über das Repository Abfragen in der Datenzugriffsschicht abgesetzt werden. In diesen Fällen hilft der Einsatz des Repository-Entwurfsmusters die sonst notwendige mehrfache Implementierung der Suchlogik zu reduzieren.

• Domain-Driven Design – Repositorys sind ein wichtiger Bestandteil des Domänenmodells von Domain-Driven Design

• Martin Fowler: Patterns of Enterprise Application Architecture. Addison-Wesley-Longman, Amsterdam 2002, ISBN 0-321-12742-0, S. 322 (martinfowler.com). 

• Edward Hieatt, Rob Mee: Repository. Martin Fowler, abgerufen am 1. Februar 2013 (englisch): „Repository mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.“ 
• The Repository Pattern. msdn, abgerufen am 1. Februar 2013 (englisch): „Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service.“