Books for software engineers and managers

Clean Architecture

A Craftsman’s Guide to Software Structure and  Design

by Bob Martin

Tech Lead,
Star Engineer

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.

Clean Architecture

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.