Books for software engineers and managers

Clean Architecture

Clean Architecture

A Craftsman’s Guide to Software Structure and  Design

by Bob Martin

Tech Lead,
Star Engineer

How strongly do I recommend Clean Architecture?
9 / 10

Review of Clean Architecture

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.

The goal of a software architect is to minimize the human resources required to build and maintain a  system

Good architecture supports high leverage. More users and more functionality supported per engineer.

Good software architecture matches system  intent

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.

The introduction of SOLID  principles

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.

Defer implementation details as long as  possible

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.

Software architecture must be  soft

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.

Well-designed components are independently  deployable

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

Code that changes for the same reasons at the same times should be grouped into a  component

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.

Architects often disproportionately fear  duplication

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.

Try to date a framework before marrying  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.

Clean Architecture