Geeks With Blogs
Greg Young Greg.ToString()

Recently I had posted some reasons about why I use Repository as opposed to Active Record. This post was originally spawned by some comments by Sam Gentile in regard to peole refactorring from repository to active record. In my previous post I listed a few reasons but one of those reasons requires much closer analysis ...

ActiveRecord seems to defeat the entire concept of DDD, ActiveRecord promotes a database centric model

Every methodology has its foundation, for Domain Driven Design it is the Repository Pattern.

People often see the repository as nothing more than a glorified factory; a simple delegation of responsibility away from the domain object. Studied in isolation on a whiteboard or in a fancy Visio diagram this is often the case. The comments are often that it is done to ease unit testing, to allow a plugin point, or to support multiple disparate data sources. While all of these items are true; they are but side effects of a greater benefit which often goes by un-noticed as the real power of the repository pattern can only be seen in it's native environment, a well designed domain.

The repository pattern with it's “objects in memory“ facade allows Domain Driven Design to become truly “Domain Driven“. Domain Driven means that we have a domain centric design methodology. This at first sounds like semantic differences but in practice the difference is night and day, and it is this difference that separates Domain Driven Design from the countless generic “business layer development strategies”. We by choice model our domain to our perceived reality and then conform the dysfunctional worlds surrounding it to meet our model.

The repository serves as our point of articulation and polarity translator between our wonderfully perfect domain and the data it needs to access which is often times on a completely different frequency than our model. By following a domain first methodology we know that we can in fact work with any exterior sources, providing we can create repositories that translate the exterior world into our model

*note* it may sound as if I am suggesting to create all repositories up front, this is not the case, normal iterations still exist.

The starting point to using repositories effectively in a domain is the creation of abstract contracts for the repositories. These abstract contracts should be the only publicly visible forms of our repositories. Internally we only use the abstract contracts to refer to our repositories and in many cases we also allow such things as dependency injection of repositories into our domain, we will generally use either a service locator or a static accessor to an instance. We also at this point create our first unit tests to test the abstract contract of a repository; we can at a later point use these unit tests as integration tests with a repository that is hooked to a real database.

When developing in a domain first process we will generally create our initial concrete repositories not only as “objects in memory“ facades but actually implement them as storing all objects in memory. I personally use a generic base class to implement these items; although it saves a huge amount of code, it is not necessary in order to produce a functional set of repositories.

As we move forward with our domain, we write our unit tests to use the in memory repositories; as the repositories actually store data in memory they are ideal for unit testing purposes. We do not at this point think again about our repositories until we are ready for integration with an actual data source.

When we have nearly completed our domain and are ready for integration, we come back and implement our repositories. We can implement them either within our domain or within the host application (that then registers them with our domain as dependencies). We have already created unit tests for the abstract contracts representing our repositories and as such should have a very strong contract for their implementation; we simply reuse the original unit tests as our base integration tests and move happily along.

When we come to our next disparate data source we simply follow the same step that we used for the first data source. As we have strong contracts defined and base integration tests written, implementing our repositories should again be a very straight forward ordeal.

There are some issues that can come up with the use of in memory repositories during the development process. Most can be seen in the creation of non-performant production code which works well during the initial development process. Care should be taken to avoid common pitfalls (such as looping through every object summing up a column). Although there is no solution to this problem outside of experience, a common pattern I have used to help alleviate this is to optionally associate a cost with my “in memory” repositories (i.e. a sleep during an object fetch). These costs are used with some very loose performance tests (run nightly) to help bring such performance issues to light.

Some others have gone this route before .. you can read about a experience here http://domaindrivendesign.org/articles/archive/rainsberger_jb_2003_10.html

Posted on Wednesday, May 3, 2006 9:21 PM | Back to top


Comments on this post: Repository, the Foundation of Domain Driven Design

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Do you know of a good example or could you post a good example of a repository?

I have read Eric Evans' book front-to-back twice and searched for a good example of a repository in the past, and I have never found one. People talk about them all the time, but you never see any code, which would speak volumes.

Do you use an O/R Mapper with your repositories and is this pretty much a necessity? Seems to me that using a base class with your repositories would require a query building language.

I would love to see an example.
Left by David Hayden on May 04, 2006 5:46 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Hey Greg,

Thanks for posting this. We aren't ignoring you - we have a lot on our plates. But Steve and I feel that many of the points you mention are totally correct. It comes down at times to certain preferences and situations as we came from a Repository pattern design. Perhaps we'll get some time to formulate a proper response soon.
Left by Sam Gentile on May 04, 2006 11:20 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Sam, I would love to hear your thoughts. I hope you did not get a badgerring intention out of this :) This topic has also been coming up in the DDD mailing list so I figured I would make an attempt at flushing out my thoughts on the subject.

I will also admit that I myself use Active Record at times, for me it is basically a conscious decision to allow my system to be database centric (a great example is when I have alot of data entry screens with comparatively little domain logic). Another time I have a tendency of using AR is when I am dealing with a system that has a mature database model (often shared by numerous other applications) already in existence.

I personally don't think there is a right or wrong answer to using repository vs active record but I will say that active record and domain driven design should be mutually exclusive.

Left by Greg Young on May 04, 2006 2:22 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Greg said ...

> I personally don't think there is a right or wrong
> answer to using repository vs active record but I
> will
> say that active record and domain driven design
> should
> be mutually exclusive.

DDD has many fundamental concepts: if I had to choose one, I'd pick the Aggregate pattern.

However, I tend to agree with you: Active Record pattern is anti-DDD, in particular because it makes difficult to provide "access boundaries". That is, using Active Record you cannot guarantee that your business objects graph will be accessed only through aggregates.

Regards,

Sergio B.
Left by Sergio Bossa on May 05, 2006 6:32 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
No badgering-). You think and write well.
Left by Sam Gentile on May 05, 2006 7:06 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
"People talk about them all the time, but you never see any code".

I've found the same to be true. The brief treatment by Martin Fowler gives you an idea of how a full example might work, but a real working example seems to be hard to find.
Left by Derek Greer on Nov 29, 2006 2:11 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
We have used repositories on the Irish Government (DSFA's) Pension System, in conjunction with Naked Objects. We start with "naive" in-memory implementations that talk to an in-memory object store, and later on during an integration phase switch to the proper implementation that hits our RDBMS . We also use Spring.NET to inject the repositories into the domain object.
Works very nicely. My website has a few more details.
Left by Dan Haywood on Apr 19, 2007 1:47 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
have you people ever heard about Hybernate?
Left by navrsale on May 01, 2007 2:59 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
"We also use Spring.NET to inject the repositories into the domain object.
Works very nicely. My website has a few more details. "

But then WTH ? You either separate the domain object or only the "design" of your domain object/repository structure ?

Isnt injecting the repository inside the domain object making the domain object an active record ?
Left by ion gion on Jan 01, 2009 2:08 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
I think in theory this works, but I'd like to see a real life example to be fully convinced. A solution does need to be found, because people rely on these services so much. I'd be lost without it
Left by Nike Goalie Gloves on Aug 03, 2009 12:20 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
he brief treatment by Martin Fowler gives you an idea of how a full example might work, but a real working example seems to be hard to find
Left by luxury Car seats on Oct 29, 2009 10:51 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
I found the same to be true. The brief treatment of Martin Fowler gives you an idea of how it could work a full example, but an actual example of work seems to be difficult to find.
Left by free xbox live on Feb 22, 2010 11:23 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Domain driven design is something that's very nice!
Left by casino on Nov 17, 2010 8:52 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
Hi thank you for an perceptive post, I actually found your blog by searching on Goole for something else nearly related, in any case before i ramble on too much i would just like to state how much I enjoyed your post. Once Again thank you very much for the blog post keep up the good work.

Gold Tips
Left by Mcx Tips on Jan 05, 2011 4:01 AM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
I am very impressed with your blog here. I really enjoyed reading your blog and I want more about this particular post.
Left by wart removal on Mar 27, 2011 7:32 PM

# re: Repository, the Foundation of Domain Driven Design
Requesting Gravatar...
What do you guys think about this (POJOS in Action - http://www.manning.com/crichardson/) book.
I think it's DDD based with examples.
Left by X30 on Feb 11, 2012 11:32 AM

Your comment:
 (will show your gravatar)


Copyright © Greg Young | Powered by: GeeksWithBlogs.net | Join free