My thoughts on clean architecture after an year

I have been using the clean architecture by Uncle Bob (Robert C. Martin) for over an year. It is something we use everyday for our development of micro services.

What is clean architecture?

Clean architecture is software development concept and practice for separating the business domain with application logic. The idea behind this is that the business logic rarely changes while the application logic and the other external entities of the application might change over the time.
There are three different sections in clean architecture. Those are the business logic, application logic and external entities (such as 3rd party APIs, databases and other libraries).
If there is a change requirement for application or external entities, clean architecture will help to keep the existing business logic intact while you can make any changes to the other sections. Clean architecture also helps to write strong unit tests to business logic expecting it to pass every time other section is changing (given that business logic does not change over time)
Clean architecture uses other practices such as dependency inversion from SOLID.

How we do it

On our organization we use our own approach for the practice. We load the external entities as class instances and inject them into the business logic at the constructor. The business logic can work on their own as long as dependencies fulfill their duty as constructor parameters.
Usually the business logic works on its own even with the drastic changes like database change or changing the application framework entirely(like changing entire database from MySQL to MongoDB).
I'm not going to jump onto code level stuff, so I will stop it here.

Pros

I am not here to show you how to do clean architecture and stuff, but to give my experience about it. There are couple of practical pros we experienced the throughout our development phases. Some of them are:

1. Maintainable solid clean code base
We know the structure of the code base, where does the database connections, API calls, repositories, adapters, controllers and models resides. We know how each of the above terms connects and communicates with each other. We know if something is in the wrong place. In other words we know which goes where, when and which. All thanks to clean architecture enforcement. This ease up the effort of code reviews and quality standards.

2. We have lot of reusable components
Since clean architecture separates external entities, we have lot of components such as adapters at our disposal that we don't have to write again.

Cons

Unfortunately I see lot of Cons instead of Pros in this manner. Let me note down the disadvantages of clean architecture

1. Lot of boilerplate code
   Unfortunately to get up and running a clean architecture you need to write lot of boiler plate code. When comparing to picking up a MVC vs using clean architecture on top of a framework, clean architecture requires lot of pre programming before actually implementing something.
2. There are no IDE voodoo magic
   I could not find any plugin to VS code or JetBrains IDEs that support clean architecture apart from directory structure generation. The support we get for well-known frameworks and libraries are awesome. But there are no such support for clean architecture.
3. Clean architecture works best with some specific use cases
   Well, certainly it is not the swiss army knife of programming paradigm. There are lot of scenarios where we can safely build without using clean architecture. The whole idea of "business logic rarely changes" is not applicable to all the problems.
4. Technology evolves so fast that maintainable code base is not actually worth it
   This is very personal opinion of mine, so take it with grain of salt. But there are lot of discussions built around this (Ex: Apple phones and Nokia phones, 2001 vs 2021). I personally believe any system that we build today will be a legacy system after the next 5 years. So we need to reengineer it to keep it up to date with the latest technology. With that, rapidly developed working software is more important than maintainable, debt-free code base.

Conclusion

Will I use clean architecture in the future? Yes, but not for everything. It actually depends on the requirement and its factors like scalability and size of the scope.

But I would not use if for all the applications that I would build in the future.