The journeylism of @yreynhout

On CQRS, DDD(D), ES, …

Suppository

Today I read Rob Conery’s piece entitled “Repositories On Top UnitOfWork Are Not a Good Idea“. While I respect Rob’s opinion and can even relate to the problems he touches upon, it made me somewhat sad as well. Why? Because it’s really telling what kind of problems people are solving using this and presumably other Domain Driven Design (DDD) tactical patterns. They are going through the motions, but they’re not getting much benefit from that investment. Probably why I’ve read so many blogposts stabbing the repository to death, with most of them seeking salvation in something closer to the metal they cherish. It’s safe to say I have a different view and opinion – what did you expect – about the benefits of the repository pattern.

If I had to summarize Domain Driven Design using 3 nouns, it’d be domain, model and language. Obviously, that doesn’t do justice to what DDD is all about, but it’s a large portion of its meat. Sadly, those 3 simple words are perceived as too abstract by many (I know this for a fact). No, I’m not going to explain them to you. There are enough Eric Evans videos going around for that purpose.
I do not tend to talk about them explicitly. But there are times, when discussing things as a team, I can point them out to you. They are, along with many other things, fundamental to doing DDD. The reason I bring them up is because many people have forgotten what the role and place of the repository is. A repository has its place in the toolbox used to carve out a model in code. It lets you deal with many issues, yet its shape won’t always be perfect or fit an actual textbook definition. Most often it’s just a seam giving you collection-like semantics. Sure, it’s handy when you can replace that seam for testing purposes, but that’s not its main motivation for being there. The needs of and the language in the model are what drive its api. Sometimes it’s used to help insulate the model from pesky technical details, horrendous legacy code or some form of elaborate translation of language we don’t want to pollute our model with. These aren’t enjoyable situations to be in, but a repository might be good enough to get the project moving on the model side and the integration side.
Collection oriented repostories aren’t the only kind. You can craft persistence oriented repositories as well, but you’ll have to be a good engineer as to not shoot yourself in the foot using them. Rob rightfully points out the transaction woes you can get in with those if you don’t watch out.
Another misconception is that repositories are somehow about views. Once you start using them for that purpose, you’re embracing a world of pain. Ultimately, reasons why you will want to combine CQ(R)S with DDD. Again, enough Greg Young videos going around for the finer details on that. I guess this is the point where I actually agree with Rob’s observations. So don’t do that. Views are hardly about solving a complex problem for which you’ll want to cultivate a language, flesh out a model over many iterations, have lots of communication and exploration.

The reason I position repositories this way is because I’m a model first guy (and no, not the Entity Framework kind). I care deeply about the things I develop from the perspective of the domain they serve. I care deeply about technical constraints, usability, performance, stability, and scalability of the software I build. It’s the journey of finding that balance between functional and non-functional requirements that is challenging and will make me bend the rules if need be. Decisions in this realm will influence what role a repository has to play, if any, in a piece of software and how it gets implemented. And yes, there are alternate – non DDD – ways of building software, which I’m perfectly okay with. It’s just not the defacto way I roll.

Summary?

Put repositories inside the model, give them an api that reflects the language of the model, use them to insulate your model from the bad and the ugly, and above all, don’t use them to feed your views.

As an aside: My friend Jef Claes already gave his point of view a few months ago, which relates to mine.

Advertisements

2 responses to “Suppository

  1. Guillaume March 8, 2014 at 11:25

    Couldn’t agree more. I had posted a comment to Rob’s article saying among others that a Repository is just supposed to be an “illusion of an in-memory collection of domain objects you can query from or add to”, which has nothing to do with the usage he depicts. For some reason, he decided to disable and hide all the comments later on.

    I think there are good ways to use Repository, if you stick to the original philosophy behind the pattern. Now some people are calling recent “trends” in Repository usage an anti-pattern. But surprisingly, what they recommend is not to use is the right way but to drop it altogether, implicitly making Repository an anti-pattern in itself. This is sad, and makes me wonder if those people even bothered to look at the original rationale behind Repository in the first place.

    • yreynhout March 8, 2014 at 11:40

      I read your comment, Guillaume, and like you I felt there was something missing from Rob’s rationale. Sadly, what Rob points out is indeed the current state of affairs for most developers. They heard about the repository pattern in the trenches without really grasping the essence, IMO.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: