Good architecture supports high leverage. More users and more functionality supported per engineer.
When you open the codebase for a fitness app, it should look like a fitness app.
We usually fail this test with:
One way to achieve an architecture that matches system intent is through components.
Components are just groupings of code that change for the same reasons.
For instance, your shopping cart app might have a PromoCode component. Anytime the promo code functionality needs changing, you are probably working within the PromoCode directory.
In addition to improving comprehension and cohesion, components help decouple logic from the framework – so you’re not as tied to Rails, Laravel, or whatever framework you’ve chosen.
SOLID principles tell us how to group code and data to support software that tolerates change, is easy to understand, and has components that can be used across software systems.
The SOLID principles are:
Clean Architecture dedicates a chapter to each principle explaining both the benefits and implementation details of each principle.
When creating a new project or adding a new feature, resist the temptation to decide technology upfront. This is often when you understand the problem least and you’re most prone to premature optimization.
For instance, defer the decision on which RDBMS to choose. You might not even need a database – simple file storage might solve the problem equally well while limiting your dependencies.
How strongly do I recommend Clean Architecture?
9 / 10
Clean Architecture is to star engineers what Clean Code is to new engineers.
While you may already implement the principles and ideas of Clean Architecture, this book will provide you the language and insights to solidify your intuition into well-articulated knowledge.
Like Clean Code, this book is great for engineering book clubs and provides an opportunity for senior engineers to mentor junior engineers.