Clean Architecture
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.
Pathway 1: I want to know everything!
- Preface
- Part I - Introduction
- Part II - Starting with the Bricks: Programming Paradigms
- Part III - Design Principles
- Part IV - Component Principles
- Part V - Architecture
- Part VI - Details
Pathway 2: I want the core ideas
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
-
Part III - Design Principles
-
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
Pathway 3: I only want to know about the architectural pattern
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
How will I benefit from this book?
Disclaimer: this is my opinion. There is no reference about these topics in the book.
If you are just starting out your programming journey
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 have already worked on non-example applications but are just starting to consider software architecture as "a thing"
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 proficient at developing software "the framework's way"
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.
If you are already fighting the framework
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 have already lost control of a large scale project
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 have been bitten by the dark side of micro-services
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.
If you are a seasoned veteran that just wants to know what is it about
Go for pathway 3.
If like the history of software and computing
The book is packed with interesting context on the history of programming languages and hardware. Go for pathway 1.
Credits and Final notes
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.