GoKawiilAs part of the SOLID principles, the single-responsibility principle (SRP) is one of the most prominent software engineering principles. Unfortunately, it is often used as a killer argument to chop up a software system beyond all recognition.
The problem with this argument is that no matter how small a component already is, the single-responsibility principle can still be applied: every line of code can be assigned its own responsibility. I've seen many teams building distributed monoliths and spaghetti code in pursuit of the SRP.
Minimize code, maximize use cases
When it comes to deciding where to place which code, I found a particular mantra very helpful: minimize code and maximize use cases. The idea is to have as many reusable software components as possible and to minimize the overall code within an organization.
Even though you might not actually have a second project where you might want to reuse something, building for reusability leads to elegant and maintainable software architecture.
The blood group law
A very concrete method on how to approach reusability can be found in Siedersleben's blood group law. This principle is part of the "Quasar architecture style" (see references below). In contrast to other vague guidelines, I find this very easy to apply in practice.
According to this method, you can categorize components into different groups. The following explanations are partly mixed with my own interpretation.
Group 0: Generic components
This is the most generic group. This code is not polluted with technical details or with business logic. In the JavaScript world Lodash, bluebird, jsonpath, Luxon, etc. would be examples of group 0 components.
... continue reading