On CQRS, DDD(D), ES, …
March 5, 2014Posted by on
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.
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.