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.
The question is always "is the team aware of the issues?" and "is management aware of the business risk technical debt poses?" and maybe "do they care?".
Software sometimes is just a means to making money and if that is what the company wants, it will throw suffering at it because clean architecture, DDD etc... although nice to have are all tangential to the ultimate purpose of it.
If you read these articles looking for generalisms, ground truths or recipes, you are setting yourself to failure. Context is always crucial to implementation.
I save time doing this. I build my application in terms of simple, testable operations on pojos. Storage is hashmaps. When I found I've built it wrong, I redo my pojos and functions. When I want to move beyond the hashmap-storage phase, I don't throw them out, I interface them and plug in a postgres connection as well. The unit tests can still run on the hashmaps.
Contrast this with what was called 'steel threads' here a while ago. You might implement some authentication end-to-end, then implement some authorisation end-to-end. You realise you accidentally put 'whitelisting' in the wrong place, and now have to spend 80% of your effort debugging opaque integration tests which test the whole system.
Keep things as simple as possible for as long as possible, identify abstractions later rather than sooner, build the system knowing it will change and optimize for as little friction as possible when that change inevitably happens.
The problem often starts with viewing software as just a project with a clear beginning and end. In reality, long-living systems are more like products or even living things—they need constant care, iteration, and a guiding hand to keep them from spiraling into chaos.
Architecture is about making those strategic decisions that help systems adapt and stay solid, even as people come and go or requirements change. Not every part of a complex system needs the same approach—some areas can be built quickly, while others need a solid foundation to avoid trouble down the road.
The goal isn’t to follow every buzzword or pretend there's one universal solution. It’s about having the right set of patterns and tools to make smart trade-offs and apply the right solutions for each part. To me, the real value of architectural patterns is that they give us common vocabulary to discuss different approaches even if we end up rejecting them. Systems need to be kept maintainable and resilient, even as they inevitably go through cycles of change.
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 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...
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).
Im also pretty happy to couple to postgres but if im working with mongo id always like an abstraction layer to let me swap out mongo one day.
Ive only once wanted an abstraction layer to swap out postgres and that's because i was forced to use azure and azure postgres appeared to be deliberately crippled in order to encourage people to switch to ms sql server.
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.