I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we get to the last major part of the Domain Driven Design picture – Repository.
In traditional architectures, your application talks to some kind of database layer, and asks it to save or retrieve your objects. DDD is slightly different, after all, remember I said “There is no database”
Of course, there is a high likelihood you do *actually* have a database, but the Repository pattern ensures you need to take little to no concern of it within your domain.
Download the eBook of the series so far …
Repository Is Just A Collection
The primary thing that differentiates a Repository from a traditional data access layer is that it is to all intents and purposes a Collection semantic – just like IList<T> in .Net
Repository Is Just A Facade
While Repository pretends to be a Collection to your domain, it is actually just a variation on the Facade pattern – it takes a complex subsystem (persistence or the database), and wraps it with a simpler interface (a Collection)
Repository Is Not A Data Access Layer
Well, at least not in the traditional sense – it doesn’t talk in terms of “data” it talks in terms of Aggregate Roots. You can tell your Repository to add an Aggregate Root into it’s collection, or you can ask it for a particular Aggregate Root. When you remember that Aggregate Roots may comprise one or many Entities and Value Objects, this makes it fairly different to a traditional DAL that returns you back a set of rows from your database tables.
Repository Is Persistence Ignorance
An important part of any properly decoupled architecture is Persistence Ignorance – your application or domain should be completely unaware of how or even if your data is persisted – it should just expect it to happen. In DDD the Repository pattern achieves this by a combination of the first three headings above – it pretends to be a collection, acts as a facade onto your actual persistence layer, and it does not act like a DAL
The Repository is the seam between your domain, and the technical implementation you use to store and retrieve your data.
Repository Is A Collection … Of Aggregate Roots
The Repository pattern is not just a thin DAL – it is responsible for talking in Aggregate Roots only. A single Aggregate may contain 2,3 or more Entities and Value objects – so our Order entity may also contain OrderLines, there would not be a Repository for OrderLines, it would be up to the Order Repository to persist an Order and all the OrderLines it contains.
What Sits Behind A Repository
Pretty much anything you like.
Yep, you heard it right. You could have a database, or you could have many different databases. You could use relational databases, or object databases. You could have an in memory database, or a singleton containing a list of in memory items. You could have a REST layer, or a set of SOA services, or a file system, or an in memory cache…
You can have pretty much anything – your only limitation is that the Repository should be able to act like a Collection to your domain.
This flexibility is a key difference between Repository and traditional data access techniques.
The Repository pattern is a Facade, that abstracts your persistence away from your Domain. On one side it pretends to be a collection – on the other it deals with the technical concerns of your persistence implementation.
Repository provides us with a mechanism to achieve Persistence Ignorance in our Domain.
InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)
1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database
5) DDD: Command Query Separation as an Architectural Concept
6) DDD: Entities and Value Objects
7) DDD: Where is the Code?
8) DDD: Download an eBook of the Series
9) DDD: Aggregates and Aggregate Roots
10) DDD: Services
11) DDD: What Kind Of Applications Is It Suited To?
del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles
02-20-2009 8:30 AM