Haters Build Software - Not Architectures

In all seriousness, and in my opinion - I don't think the goal of a software design should ever be to satisfy some particular architectural style.

I think that's nonsense, really do.

First and foremost, the primary goal is, of course, to satisfy your functional requirements.

The secondary goal is to achieve specific system attributes (also known as the "ilities" - look it up).

ility (plural ilities) (software engineering) An abstract quality that good software should exhibit. One reason to use software libraries is that the authors have had time to add ilities in addition to the basic functionality.

There are quite a number of these. In fact, Wikipedia says there are 80+ attributes your system may have.

That's a lot, but that's not the only issue.

Some ilities will be derived from your functional requirements. For example:

• High Availability. That's an architecturally significant requirement that is a feature that allows your users to accomplish their tasks.
• Scalability. Imagine you are building software in a football domain, and every two years during the Euro Cup and the World Cup, the number of concurrent users is *10,000 (at least). You need to plan and design for that scalability requirement, and again, that is a feature that will allow your users to accomplish their tasks (during those Cup games).

But that's not all.

Some "ilities" (or architecturally significant requirements to be academic about it) - are in direct contradiction with each other (or you can't have them all).

For example, you want high Maintainability (which implies Changeability and Flexibility), and you also want high Security.

Not happening.

Well, high Security assumes that you'll be introducing a couple of new layers of security; you want to have, of course, fine-grained user roles; of course, you'll need to have attached permission on those roles, permissions will have policies, and then you'll need to defined policies, perhaps on a row- level, then you need to think about row-level policy execution, etc., etc., and of course, you'll need a special and separate application that will manage all that, and finally, someone (meaning you) will have to maintain all of that, so much for maintainability.

And, finally, those "ilities" may apply to just one portion of a system, may depend on your environment, etc.

The point is that the goal of software architecture is not to achieve the pureness of a particular architectural style (Clean Architecture, for example).

Your goal should be to satisfy architecturally significant requirements (or "ilities") that are the result of careful and thorough analysis, so you may end up with a system that has specific system attributes you designed for.

That's a mouthful, but it is what it is, which brings me finally to the Clean Architecture (TM).

Correct me if I'm wrong, but according to Lindkein's posts and comments, the number one benefit of Clean Architecture is as follows:

1. 𝗜𝗻𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝗲 𝗳𝗿𝗼𝗺 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀: Clean Architecture doesn't tie you to specific tools or frameworks. This allows you to swap out database ORMs, web frameworks or libraries without impacting the core business logic.

... umm, I have questions ... 🤔

So basically, your "ilities" are already set for you; you don't have to do anything - regardless of your system's unique requirements.

And I need to figure out where even to start with this...

• Swapping databases. I've done it only once, like 15 years ago, and it was nerve-wracking. As far as I can see, that is the case with other people, too. Swapping databases is a very rare and extraordinary occurrence. But even that is always one RDBMS type for the other. I have never heard that someone swapped RDMBS for Docubase or Key-Value Storage just like that.
• Swapping ORM's. Well, the entire idea with ORMs is that they can abstract your RDBMS so that you can swap your RDBMS database more easily. And they do help in that regard, I admit. But swapping ORM? Lol, are you kidding me? I have heard only once in my career that there was a need to replace the ORM library, basically, some exotic ORM library became unsupported and needed to be replaced with the supported one. But that implied literally rewriting everything from the ground up. So, essentially, we should be able to swap the thing that allows us to swap the other thing. Got it.
• Swapping web frameworks. Now, this is just ridiculous. I'm not going to comment on that. Never even heard of such a thing.

Since I'm now considered as the "Clean Architecture" hater (ok, I admit, I am), and, also, I'm asked to provide an alternative, so here it is:

• Carefully and thoroughly analyze your system, your requirements, and your environment - to distill your architecturally significant requirements. Find out what your "ilities" are and prioritize them accordingly.
• Select the most appropriate database (PostgreSQL is always a good choice, but there are others like Snowflake, BigQuery, MariaDB, etc.) - and get the most out of it. You'll find out that are extremely powerful, capable, and feature-rich.
• Don't abstract it away because the architectural flavor of the day says so - do it instead because your "ilities" say so. And they rarely do. Otherwise, you'll be denied many of those powerful features.

I'm not in a business telling other people what to do, I'm in business telling computers what to do.

But I wanted to say this given the amount of discussions lately over the Clean Architecture.