By: Robert Cecil Martin

This is a detailed summary of the Clean Architecture book. The summary covers every chapter of the book. However, I believe the core ideas of the book can be picked up by reading a smaller sub-set of chapters.

You will find different "reading pathways" below that will help you explore or refresh the concepts in the book depending on how deep you want to go.

• Preface
• Part I - Introduction
• Part II - Starting with the Bricks: Programming Paradigms
• Part III - Design Principles
• Part IV - Component Principles
• Part V - Architecture
  • This is the main part of the book. I've divided it into two sub-parts to assist reading.
    • Subpart 1
    • Subpart 2
• Part VI - Details

I believe that the sections presented below distill the most important ideas.

Note that the book is full of nuanced rich details on when and how much to invest in architecture according to your project's characteristics. It also covers how to soundly compromise some of the architectural boundaries for the sake of simplicity.

Understanding these nuances is very important to develop your architectural critical thinking and is one of the main points of the book. Unfortunately, none of these detailed ideas are captured in the plethora of blog posts and youtube videos about Clean Architecture, so I recommend you read at least the following sections.

• Part II - Starting with the Bricks: Programming Paradigms

  • Chapter 5 - Understand why the dependency inversion is important

• Part III - Design Principles

  • Chapter 7 - The Single Responsibility Principle

• Part V - Architecture

  • Chapter 15 - Good architecture is about keeping options open
  • Chapter 16 - Vertical and Horizontal Layers and Independence
  • Chapter 17 - The Plugin Architecture - The Foundational Idea of Clean Architecture
  • Chapter 19 - Policy and Level
  • Chapter 20 - Business Rules
  • Chapter 21 - Screaming Architecture
  • Chapter 22 - The Clean Architecture
  • Chapter 24 - Partial Boundaries
  • Chapter 25 - The Cost of Implementing VS Ignoring Boundaries
  • Chapter 26 - The Main Component, The Ultimate Detail
  • Chapter 27 - Services and Microservices
  • Chapter 28 - The Test Boundary

• Part VI - Details

  • Chapter 30 - The Database is a detail
  • Chapter 31 - The Web is a detail
  • Chapter 32 - Frameworks are details
  • Chapter 33 - Case Study: Video Sales
  • Chapter 34 - The missing chapter - Actual implementation details of an architecture

In that case just watch this 1 hr youtube video and read the chapters below.

Note that you will probably be missing an important point of the book as you won't learn about the bits that develop your architectural critical thinking. If you miss this point, you may (incorrectly) find the ideas too idealistic, far removed from programming reality and even dogmatic.

• Chapter 16 - Vertical and Horizontal Layers and Independence
• Chapter 22 - The Clean Architecture
• Chapter 33 - Case Study: Video Sales

Disclaimer: this is my opinion. There is no reference about these topics in the book.

If you are still getting comfortable with building applications using a framework like Rails, Django, Spring or Laravel, you probably won't appreciate the full depth of the ideas yet.

I recommend you put this on your reading list and come back later. The ideas in here won't become dated.

If it is still early in your career but you have already built at least one production application on your own or with a small team, you will likely find that part of the clean architecture ideas map with some patterns you have developed organically.

Probably, you will also find that ideas like Vertical and Horizontal Layers finally give some structure to the burning questions you already have about how to organise your code.

I recommend you go for pathway 2 and if you like what you see read the whole thing.

If you are very comfortable with one framework, fully embrace it's way of organising code and have found workarounds to reduce every possible problem to "the framework's structure" (e.g. everything has to become a model or view or controller), you will find the clean architecture ideas challenging and possibly disruptive to the way you are used to work.

I very strongly recommend you read it (pathway 2 or 1). You will gain a very different perspective about building software and representing business logic in code.

You will gain some insight on how to code in a way you actually control your code (as opposed to the framework controlling it) and on using the framework as tool in the bits that is really needed.

There may still be a bit of framework wrestling involved, but at least you will now know how to limit the blast radius of the fight.

Go for pathway 2.

If you already work with multiple people maintaining a Big Ball of Mud, this book will help you and your team build a common understanding on how to build new features while keeping them isolated from the big ball of mud. Hopefully, it will also give you some ideas on how to progressively refactor the important bits from the ball.

Go for pathway 2 or 1.

If you ended up with a distributed monolith and are having difficulties coordinating deployments between services that are coupled, you will learn that micro-services is NOT an architecture, it is a Decoupling Mode.

The book will help you develop a better critical thinking on when micro-services make sense and how to organize code inside a monolith that is ready to be extracted as a micro-service if the operational conditions demand it.

Go for pathway 2.

Go for pathway 3.

The book is packed with interesting context on the history of programming languages and hardware. Go for pathway 1.

The summary might be full of typos, formatting errors and some spelling mistakes. I was not optimising for an editorial quality; these are just the quick notes I took while reading the book. If you want to fix something please open an issue or send a PR and I'll happily change it.

I've re-used and augmented some of the diagrams in the book to explain the concepts more clearly. All credit for the diagrams and ideas should go to Mr. Martin.

Mr. Martin has been involved in multiple controversies lately. My intentions with this repo are to help others on their software architecture journey and to provide an objective summary of the book's content. Please don't associate me in these controversies for summarizing a book.