I’ve recently written a couple of posts (first one is here, second one is linked from the top of that one) arguing against precisely this type of “hide the ORM” approach to building Django apps. The thing I initially reacted to preferred the “service layer” terminology, while this one prefers the “repository” terminology, but the arguments are the same either way.
There are two groups of people. Those who think this is a good idea. And those who have worked on projects that implemented these ideas.
These “abstraction is so cool” ideas are the diet fads of software engineering. They look good and they sound convincing but somehow they just don’t work and once one of them gets old another one is just around the corner waiting to lure you in with new promises.
they just don’t work
they just don’t work
Could you explain why? Or share articles that explain your opinion?
We can have a never ending conversation on the topic but I’ll give you a bunch of summary bullet points.
Simplicity wins: More abstraction is not inherently a good thing. Abstraction quickly compounds and increases cognitive overhead beyond your capacity, and we all over-estimate our capacity. Adding these “logical” layers of abstraction creates indirection and obfuscation. You don’t need to model the entire world in your programming language to read or write some values in a database.
Your pretty diagrams don’t exist in the real world: Real world is hard and dirty. Just because these ideas exist cleanly in a textbook it doesn’t mean you will find them that way in real world projects. In practice you will inherit a large project touched by hundreds of people with varying levels of skill and care. Nothing I say here is going to make you feel it until you are thirty six call frames deep into debugging AbstractCustomerConnectionManagerProxyBeanRepositoryFactory at 7:30pm on a Friday night.
And no “they didn’t do it right” is not a valid defense. If most of the time something can’t be done right I don’t want it. I don’t care if it’s the fault of the people or the idea. That’s irrelevant.
Diet fads vs First principles: Just like diet fads software fads are pushed a lot by people that do a lot of talking and not a lot of doing. The loud celebrities are busy telling everyone how they’ve been doing it wrong all this time. This time for real, if only you buy their latest shiny “Clean Bullshit” book and sign up your company for their expensive consulting services. Meanwhile the humble quiet practitioners are just getting it done without turning all Socrates about everything. The first principles prevail while the fads keep changing. This is the difference between chasing books and secrets and magic diet pills vs someone who just lowers their calorie intake, and increases their calorie burn. Doing the simple thing is hard. Distracting yourself with good intentions is easy.
Pragmatic craftsman vs Gatekeeping philosopher: Ultimately what matters is the outcome. When the simple elegant solution of the pragmatic craftsman outperforms the complex buzzword-ridden solution of the fad-chasing astronaut it is the pragmatic craftsman who has something to teach, not the other way around. The gatekeeping philosopher has something to sell that is of no use or value to the craftsman who knows how to get shit done. Yet the gatekeeping philosopher goes around the town insisting that everybody is doing it all wrong. They try to constrain the pragmatic craftsman by outlawing their craft. That’s why most of these fads come with “if you are not doing it like me you are doing it wrong” vibe.
For a humorous relevant link also see: http://programming-motherfucker.com/
Thank you very much for your comment. It definitely reads very pessimistic, but it’s helpful to get another viewpoint on the topic.
I’ve never practiced DDD, I’ve just read about it and it felt powerful and like a very sensible methodology. Although, I’m no fool and no silver bullet exists. Therefore, I’m a bit skeptical and welcome other viewpoints like yours.
I once worked on a codebase that used a “service layer” in front of a Data Mapper ORM. I could understand doing one or the other, but doing both in the same project was just weird. And in the end it didn’t provide much in the way of portability when the team made a decision to switch frameworks.