Even worse, their approaches often fall under Architect Astronauts, blabbering about abstractions and patterns much more than about actual business domain concepts.
Time and time again, just building it has proven a much more fruitful concept than producing thousands of pages about the architecture before building. Even in projects where forethought is required, the usual documents are about specifications and business considerations, not whether you will use the Facade Pattern or the Ballsack Ring pattern.
Furthermore, while Gang of Four was cool, everyone now is proposing their own patterns and names and there is, nor will ever be a consensus, so you are forced to learn thousands of disparate namings for intersecting or repetitive "patterns" and architectures that have no bearing on software itself nor any significant history other than Uncle Bob posted it on a blog post. It's never the Nasa Mars Rover pattern or the OpenAI metrics pattern, it's always a thought from an online architecture pundit.
It's starting to feel like Software Architecture is the frenology of software. Just safely disregard it and continue reading about more tangible topics.
I’ve had great success by not using a database abstraction layer:
- you can invest the time you spend on being a generalist on many databases to be a real expert on one
- no more fighting the abstraction layer; use any persistence feature directly
- better perfomance is easier to achieve
- simpler data modelling and execution
- simpler backups
The list goes on tbh.
Drawbacks? Well yes: you have to make a really good decision on your dbms (hint: psql). But that’s actually an advantage deguised as a drawback: wanting to be able to easily change the dbms is just fearing making decisions. It’s like requestibg a car where you can swap out any type of engine.
(Also, use a single dbms. Really. There’s nothing any nosql can do that psql/mysql can’t do (mayve vice verca) unless maybe in really specific cases).
I hate this pattern from the very bottom of my heart. Now I cannot simply follow the call of a function with the help of my IDE anymore, no, I'll have to awkwardly search for a handler that processes the query/command in question. Figuring out what a specific API endpoint actually does in such an architecture is a cruel nightmare of indirection and boilerplate. And all that because some overambitious dev desperately wanted to build a "high-level task execution pipeline" for the joy of it...
The benefit is that it can map nicely onto how existing processes work. You can sit with people in a meeting, they can describe their processes (by something as simple as passing post-it notes around the table), and those post it notes then directly become the basis of your system design.
Not that this is the only way to achieve that, but it is _a_ way.
I'm yet to see a project that was clean from inception to retirement. They seem to go through waves. Starts clean, get messy, a big clean up happens, happy days, back to messy, then comes the permanent architecture which is reasonable, and it gets slowly messier through maintenance updates and developers become too scared to wake the dragons...
Most of the devs move onto the next green project and ride the refactoring choochoo once again, having learnt almost nothing in the process and chasing the newest shiny abbreviations that ensures that this time, it will be different!
These types of graphics and biblical design akin to "this is the way" always put a smile on my face.