There are too many architecture blog posts already, and I am guilty of writing a few myself here and there. The sheer number of such articles tells a story of its own: no one has the grand recipe for the one architecture superior to all others. It doesn't exist. (Also, everyone can write stuff on the Internet.)

Some go even further and translate their posts into source code and publish them as an architecture you can import and use in your project. In that moment, it becomes something different. GitHub repositories named whatever-Architecture are often just fancy-dressed frameworks: a set of tools with another set of opinionated rules you must adhere to for it all to work.

Once you build your app on top of the framework, it's not just a harmless import you can later remove; it's a marriage. You're in it in sickness and in health, for better or for worse. You have to accept the decisions of others, embrace them as your own, and learn to live with them. It's neither bad nor good; it's just a decision that needs to be carefully made because divorcing such a framework is a nasty business, so double-check the scales and see whether the toolset the framework brings is worth the control you give up.

When you design your architecture, you don't give up any control and can decide which aspects to fine-tune, which corners to cut, and which parts to future-proof. Nothing is set in stone. Once you change your mind, you can quickly revisit or postpone any decisions. The ability to quickly change is an essential software feature, and the architecture is the tool to enable this.

Frameworks let you focus on implementing user-facing features. Good architecture enables you to decide and control product and business-facing features on top of that.