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.

Soft architectures are open to change, they are not fixed. Soft architectures can be changed in response to changing environments and the realities of customer needs. The architecture you had at the start of a project can and should change as your program evolves.

Independent deployability helps teams deliver faster. Boundaries are clearer between teams. Tests and builds run faster. Problems become more isolated.

Sometimes we swing too far with modularity, splitting code along too granular of lines. We know we’ve over-modularized our code when we must change several components in order to deliver a change. For instance, within an API if we want to build a new API endpoint, it should generally not involve changing multiple components but rather one. The author calls this the Common Closure Principle.

True duplication happens when changing one instance results in changes to other instances. True duplication is bad.

Accidental or false duplication happens when two seemingly duplicated code blocks evolve differently, changing at different times and for different reasons. Architects should not fear this type of duplication and should be careful to not prematurely optimize against it.

When writing an application based on a framework, look for ways to depend on the framework less. General purpose frameworks address lots of use cases that won’t be applicable to the problem you are trying to solve. Perhaps you can find a lighter way to use the framework or you can eliminate it entirely.