Clean Architecture

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:

1. Systems built on generic content management systems. The underlying code often looks indistinguishable from a blog or news site.
2. Systems built on popular frameworks like Rails or Laravel. When you open these codebases, you get the feeling of “Oh, this is a Rails app” not “Oh, this is a shopping cart app.”

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:

• S – The Single Responsibility Principle (a slight misnomer)
• O – The Open-Closed Principle
• L – The Liskov Substitution Principle
• I – The Interface Segregation Principle
• D – The Dependency Inversion Principle

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.