Every now and then I read a piece about DRY vs WET, explaining their benefits over its counterpart. Most of the time, these pieces are quite unhelpful, as they are way too vague and general. They lack a crucial thing, and that is context. I believe this is the most common aspect on disagreements about any topic in software development. Someone writes a piece about X or Y topic arguing a point, but then another piece comes up arguing a different case (or sometimes totally the opposite one).
Not long ago some of my CI pipelines failed in its psalm step. The error was due to an exception that could not be caught, because it was not an exception class. The culprit, the 1.1.1 version of psr/container, had removed extends Throwable from the Psr/Container/ContainerExceptionInterface. Here is the related issue. Now, this was all done to a language support issue, which is understandable. But this exposed a somewhat related issue.
Last year I built a multitenant system for my employer Spatialest. It was my first time doing a multitenant system, so I researched a lot before doing it. I studied carefully the experience of platforms like Shopify, as their multi tenant requirements were similar to ours. But even after some careful study, I made some mistakes. One of those mistakes is what I’ve come to call tenant pollution. This means that many services or routines need the tenant as an argument in order to do something.
The Discovery of a Syndrome The past week I had some really nice holidays, but my wife still had to work. That’s nice sometimes because it means staying at home with loads of time to do one of my favorite things: getting myself into learning and coding (I also did some cleaning, cooking and DIYing too!). I was surfing YouTube for good coding talks and one caught my attention. It was Jack Diederich’s PyCon 2012 talk entitled “Stop Writing Classes”.
Introduction: A Tale of Simplicity VS Complexity NOTE: Every time the word array is used in this article I’m referring to the PHP definition of this term. You can also consider that term equivalent, for the purposes of this article only, to use instances of stdClass or instances of classes that contain dynamic public properties, like Active Record Models. This is because the deficiencies pointed with arrays apply to those constructs as well.
We were extremely warned about the dangers of microservices, but we implement them anyway. Now, we are slowly realizing that we should have never, ever, abandoned the monolith. Our multiple failures at microservices probably speak of two things, (1) we probably lack the workforce and proper Ops team to carry this effort onward and (2) we probably could have solved our problem without them anyway. Note that I’m saying that microservices are fine.
The repository pattern is one of the most well established patterns in Domain Driven Design. It’s origins can be traced as early as when Object Oriented Programing was born. Of course, like it happens with almost every pattern or tool, you can really use it terribly the first time (or even the second, or the third one). The only way to improve upon that is good literature and seeing other, more appropriate, uses of the pattern/tool.