What do you think?
Rate this book
Robert C. Martin Series
Clean Architecture
Building upon the success of best-sellers The Clean Coder and Clean Code, legendary software craftsman Robert C. "Uncle Bob" Martin shows how to bring greater professionalism and discipline to application architecture and design.
As with his other books, Martin's Clean Architecture doesn't merely present multiple choices and options, and say "use your best judgment": it tells you what choices to make, and why those choices are critical to your success. Martin offers direct, no-nonsense answers to key architecture and design questions like:
What are the best high level structures for different kinds of applications, including web, database, thick-client, console, and embedded apps?
What are the core principles of software architecture?
What is the role of the architect, and what is he/she really trying to achieve?
What are the core principles of software design?
How do designs and architectures go wrong, and what can you do about it?
What are the disciplines and practices of professional architects and designers?
Clean Architecture is essential reading for every software architect, systems analyst, system designer, and software manager — and for any programmer who aspires to these roles or is impacted by their work.
As with his other books, Martin's Clean Architecture doesn't merely present multiple choices and options, and say "use your best judgment": it tells you what choices to make, and why those choices are critical to your success. Martin offers direct, no-nonsense answers to key architecture and design questions like:
What are the best high level structures for different kinds of applications, including web, database, thick-client, console, and embedded apps?
What are the core principles of software architecture?
What is the role of the architect, and what is he/she really trying to achieve?
What are the core principles of software design?
How do designs and architectures go wrong, and what can you do about it?
What are the disciplines and practices of professional architects and designers?
Clean Architecture is essential reading for every software architect, systems analyst, system designer, and software manager — and for any programmer who aspires to these roles or is impacted by their work.
432 pages, Paperback
First published September 1, 2017
3144 people are currently reading
14279 people want to read
About the author
Robert C. Martin
65 books1,877 followersRobert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 494 reviews
October 25, 2017
I really liked this book but also was a bit disappointed by it. I'm a huge fan of Robert Martin's work, I've read his previous books and I love Clean Code and The Clean Coder. Based on the title and artwork I had kind of assumed that this was just the next step of the Clean Trilogy, this time focusing on architectural concerns.
It is kind of that, but it's mostly not quite that. Really, this book is a lot of background information to understand the "meat" of the book, and the meat of the book is Martin presenting his Clean Architecture pattern, which he proposed in 2012 and has been presenting and training a lot on: https://8thlight.com/blog/uncle-bob/2...
In that way, this book feels much more specific than Clean Code or The Clean Coder. While those two books are general advice for software professionals, this comes off more as an extended design pattern book that only covers one singular pattern. It's presented as The Only Right Way, and while I personally agree with Martin's perspective and his loathing for framework-heavy architectures, it was a bit disappointing that the book was mostly a very deep dive on a blog post from five years ago.
The "buildup" stuff is actually more interesting. It's about applying SOLID principles to architecture and I really enjoyed this section of the book, I felt like I finally grokked dependency inversion at a component level, and there's a lot to apply to architectural problems I face. That section of the book feels very general, though like most of Martin's work it's yet another rehash of SOLID and talking about FitNesse, two things he's gotten a stunning amount of mileage out of to a point where you kind of wonder if he's ever done anything else (he has, but boy does he return to these wells a lot).
In a way this is two shorter books smashed together. One is Clean Architecture, a book about building clean architecture using SOLID principles (and a few new ones). The other is a book about the Clean Architecture Pattern, a particular way to architect systems that shares a lot with Allistair Cockburn's Hexagonal Architecture pattern. These two concepts use the exact same name to, I think, intentionally get readers to conflate the two concepts as one and come away feeling like Martin's proposal is the only possible way to architect a system in a way that is clean. But one of these things is "clean architecture" and the other is "Clean Architecture", and it's often hard to see what is what. This is by design, I think.
In any case, the book is really good and I got a lot of out of it, though it wasn't what I was expecting really. The first half (or so) of the book feels like 80% rehash of stuff I've seen from Martin before, with 20% extremely good and useful new stuff. Then the second half of the book is a completely different topic presented as the same topic, which I enjoyed but I can see a lot of readers being turned off by. I still would recommend the book and I think it's worth reading for anyone who feels like "architecture" is part of their job.
It is kind of that, but it's mostly not quite that. Really, this book is a lot of background information to understand the "meat" of the book, and the meat of the book is Martin presenting his Clean Architecture pattern, which he proposed in 2012 and has been presenting and training a lot on: https://8thlight.com/blog/uncle-bob/2...
In that way, this book feels much more specific than Clean Code or The Clean Coder. While those two books are general advice for software professionals, this comes off more as an extended design pattern book that only covers one singular pattern. It's presented as The Only Right Way, and while I personally agree with Martin's perspective and his loathing for framework-heavy architectures, it was a bit disappointing that the book was mostly a very deep dive on a blog post from five years ago.
The "buildup" stuff is actually more interesting. It's about applying SOLID principles to architecture and I really enjoyed this section of the book, I felt like I finally grokked dependency inversion at a component level, and there's a lot to apply to architectural problems I face. That section of the book feels very general, though like most of Martin's work it's yet another rehash of SOLID and talking about FitNesse, two things he's gotten a stunning amount of mileage out of to a point where you kind of wonder if he's ever done anything else (he has, but boy does he return to these wells a lot).
In a way this is two shorter books smashed together. One is Clean Architecture, a book about building clean architecture using SOLID principles (and a few new ones). The other is a book about the Clean Architecture Pattern, a particular way to architect systems that shares a lot with Allistair Cockburn's Hexagonal Architecture pattern. These two concepts use the exact same name to, I think, intentionally get readers to conflate the two concepts as one and come away feeling like Martin's proposal is the only possible way to architect a system in a way that is clean. But one of these things is "clean architecture" and the other is "Clean Architecture", and it's often hard to see what is what. This is by design, I think.
In any case, the book is really good and I got a lot of out of it, though it wasn't what I was expecting really. The first half (or so) of the book feels like 80% rehash of stuff I've seen from Martin before, with 20% extremely good and useful new stuff. Then the second half of the book is a completely different topic presented as the same topic, which I enjoyed but I can see a lot of readers being turned off by. I still would recommend the book and I think it's worth reading for anyone who feels like "architecture" is part of their job.
November 26, 2018
Such a sad and useless book. Let me save you time and money by summarizing the entire book in one deceitful sentence: "Use interfaces to hide implementation details." Done. Now you can go spend your $30 on something better. Like beer.
Of course the best part of it all is that now there is an army of bro-coders out there thinking that they know what's up, so every single code package they check in has a useless interface per every "implementation" class.
Here is a life pro-tip: if you ever stumble upon two files, one of them being an interface named, say, OrderService and another an implementation of that interface ending with -Impl, like OrderServiceImpl, please do everyone a favor and just merge the two. The sole fact that someone had to add -Impl to the class name means that there will never be a second implementation, so the interface they defined is useless and needs to be obliterated into the void. It's just garbage code that clutters the project structure. Maybe, just maybe, if we all follow that rule then the common sense will eventually prevail. Until then, God help us all.
Of course the best part of it all is that now there is an army of bro-coders out there thinking that they know what's up, so every single code package they check in has a useless interface per every "implementation" class.
Here is a life pro-tip: if you ever stumble upon two files, one of them being an interface named, say, OrderService and another an implementation of that interface ending with -Impl, like OrderServiceImpl, please do everyone a favor and just merge the two. The sole fact that someone had to add -Impl to the class name means that there will never be a second implementation, so the interface they defined is useless and needs to be obliterated into the void. It's just garbage code that clutters the project structure. Maybe, just maybe, if we all follow that rule then the common sense will eventually prevail. Until then, God help us all.
December 16, 2017
This is the first book of Uncle Bob that I didn't like – it's shallow, impractical, and full of stories from forgotten 90's. A significant part of the book (explanation of SOLID principles) has been copied (with few alternations) from "Agile PPP" book, which is, in my opinion, a much more thorough book.
To understand modularity patterns mentioned in this book, I suggest taking alternative path – reading "Java Application Architecture" by Kirk Knoernschild.
In addition to modularity and SOLID, the book tries to explain Hexagonal Architecture (a-ka Clean Architecture). Just Google it to grasp the idea and then read "Java Application Architecture".
The ideas mentioned in the book has practical application and are beneficial in some contexts. The problem is that the context is not set, and drawbacks were not properly examined. The book also lacks practical examples (the case study takes only 2 pages).
There a chapter that I like, though – it's a chapter written by Simon Brown (on packaging). In order to understand the idea, you can read Simon's blog post "An architecturally-evident coding style". Also, Simon wrote a great book – "Software Architecture for Developers".
To understand modularity patterns mentioned in this book, I suggest taking alternative path – reading "Java Application Architecture" by Kirk Knoernschild.
In addition to modularity and SOLID, the book tries to explain Hexagonal Architecture (a-ka Clean Architecture). Just Google it to grasp the idea and then read "Java Application Architecture".
The ideas mentioned in the book has practical application and are beneficial in some contexts. The problem is that the context is not set, and drawbacks were not properly examined. The book also lacks practical examples (the case study takes only 2 pages).
There a chapter that I like, though – it's a chapter written by Simon Brown (on packaging). In order to understand the idea, you can read Simon's blog post "An architecturally-evident coding style". Also, Simon wrote a great book – "Software Architecture for Developers".
September 30, 2017
Some key remarks I have:
1. Even if it may look (at some point) deceptively simple, ... it isn't. In fact, the most valuable lessons will be truly comprehensible (& clear) only for people with certain level of experience.
2. This book doesn't try to cover anything in particular in the end-to-end way, it's more about certain aspects of software architecture Uncle Bob finds most important (e.g. SOLID principles, boundaries, proper approach to composition, etc.). Needless to say - these are universal & technology-agnostic (which is good), but they are most applicable to typical OO languages & platforms.
3. Appendix (that takes ~20%-25% of the book) is quite personal, quite impressive, but ... not really entertaining or educative. But well, it's Uncle Bob, so such things can be forgiven ;)
Is it a good, valuable book for an aspiring or even experienced architect? I think so - I like its focus on principles instead of patterns & I personally think this is something we truly need to be reminded about.
1. Even if it may look (at some point) deceptively simple, ... it isn't. In fact, the most valuable lessons will be truly comprehensible (& clear) only for people with certain level of experience.
2. This book doesn't try to cover anything in particular in the end-to-end way, it's more about certain aspects of software architecture Uncle Bob finds most important (e.g. SOLID principles, boundaries, proper approach to composition, etc.). Needless to say - these are universal & technology-agnostic (which is good), but they are most applicable to typical OO languages & platforms.
3. Appendix (that takes ~20%-25% of the book) is quite personal, quite impressive, but ... not really entertaining or educative. But well, it's Uncle Bob, so such things can be forgiven ;)
Is it a good, valuable book for an aspiring or even experienced architect? I think so - I like its focus on principles instead of patterns & I personally think this is something we truly need to be reminded about.
February 4, 2019
I'm very disappointed with this book. I had very high expectations of it after having read Uncle Bob's excellent "Clean Code" and "The Clean Coder", but after reading this, I can only feel that my money's only purpose was to help the author set up a second gold-coated swimming pool at their mansion - there was little to learn here.
I would divide the book in two halves. The first of these hardly bears any relevance at all - it's mostly anecdotes and stuff that (in my opinion) doesn't really need to be in a book about architecture, particularly so if you already have any knowledge of design patterns. (Seriously, why bother explaining structured, object-oriented and functional programming?) The second half is where you'd expect the meaty content to be, but at the end of the day most of it can't be summarized in a simple sentence: don't do coupling. Don't do coupling in your database, don't do coupling in your services, don't do coupling in your web frontend... and a chapter for every single place where you want to avoid coupling.
To be fair, there is a couple of gems and useful pieces of information scattered across the book, but even in these cases, many of them were underexplained. Too much attention is paid to unimportant topics and too little to the points I found the most relevant.
It is rather sad that the only chapter that I found useful from start to end is called "The Missing Chapter". Perhaps the name is indicative of the fact of how difficult it is to fit a single useful chapter into an otherwise mostly pointless book.
I would divide the book in two halves. The first of these hardly bears any relevance at all - it's mostly anecdotes and stuff that (in my opinion) doesn't really need to be in a book about architecture, particularly so if you already have any knowledge of design patterns. (Seriously, why bother explaining structured, object-oriented and functional programming?) The second half is where you'd expect the meaty content to be, but at the end of the day most of it can't be summarized in a simple sentence: don't do coupling. Don't do coupling in your database, don't do coupling in your services, don't do coupling in your web frontend... and a chapter for every single place where you want to avoid coupling.
To be fair, there is a couple of gems and useful pieces of information scattered across the book, but even in these cases, many of them were underexplained. Too much attention is paid to unimportant topics and too little to the points I found the most relevant.
It is rather sad that the only chapter that I found useful from start to end is called "The Missing Chapter". Perhaps the name is indicative of the fact of how difficult it is to fit a single useful chapter into an otherwise mostly pointless book.
July 2, 2019
As a frontend developer it is my first book about design principles and architecture. It gave me a good understanding of what are union architecture, hexagonal, port and adapters, layered, and of course clean architecture. However in the Javascript world things are different. Mapping these concepts in FrontEnd needs a lot of effort. But about the book, it is Comprehensive, easy reading and easy following.
September 27, 2018
Overall a good book, you will learn few things from it, or at least it will be a good refresher, although it is not bringing any new ideas, worth reading if you like uncle Bob.
February 4, 2020
First of all, I am a huge fan of Uncle Bob. I have red "The Clean Coder" and "Clean Code" which I really found very helpful.
Regarding this book, I felt like I was reading the same thing again and again. It was all about using interfaces and hiding your business logic and implementation details. It's about using the SOLID principles into the design of your architecture. It's about using components. Also, the Microservices and SOA architectures were mentioned but I didn't liked the explanations. There was nothing about messages and events.
Overall, I do not recommend this book. It is better to read the other books from Uncle Bob but this one, in my opinion, is not worth it.
Regarding this book, I felt like I was reading the same thing again and again. It was all about using interfaces and hiding your business logic and implementation details. It's about using the SOLID principles into the design of your architecture. It's about using components. Also, the Microservices and SOA architectures were mentioned but I didn't liked the explanations. There was nothing about messages and events.
Overall, I do not recommend this book. It is better to read the other books from Uncle Bob but this one, in my opinion, is not worth it.
December 3, 2017
Many of the reviewers who rated it low misunderstood the book. I see in the reviews that they expected microservice, CQRS and other "architecture" descriptions. But this book is about something different. This is about the "clean" architecture. Yes he uses SOLID to describe architecture components, but from the different angle than talking about the code.
The book also is a good read just because of the style and story. Uncle Bob always is a good storyteller.
Just read and enjoy the book. Do not expect it to describe some new architecture style. Read it as a novel.
The book also is a good read just because of the style and story. Uncle Bob always is a good storyteller.
Just read and enjoy the book. Do not expect it to describe some new architecture style. Read it as a novel.
April 19, 2018
Interesting, but too long with too many not needed and off-topic anecdotes. Still worth your time, but not as insightful as previous titles from "Clean X" series.
June 16, 2023
March2022:
I didn't understand everything, yet I learned soo much and I am stunned.
This book covers every dimension, from small-scale function level to entire application-level-scale. It presents various principles for designing software that structure it logically and make development, maintenance and augmentation way easier. It also incorporates the necessary nuance.
Very strong. Though it presents advanced high-end concepts for designing large-scale applications, which aren't all super-applicable for me, I learnt a lot.
June2023:
Very good book covering architecture from low to high-level scopes. I would summarize it with the Dependeny Principle: Dependencies should ALWAYS point from low-level to high-level code.
I didn't understand everything, yet I learned soo much and I am stunned.
This book covers every dimension, from small-scale function level to entire application-level-scale. It presents various principles for designing software that structure it logically and make development, maintenance and augmentation way easier. It also incorporates the necessary nuance.
Very strong. Though it presents advanced high-end concepts for designing large-scale applications, which aren't all super-applicable for me, I learnt a lot.
June2023:
Very good book covering architecture from low to high-level scopes. I would summarize it with the Dependeny Principle: Dependencies should ALWAYS point from low-level to high-level code.
February 26, 2019
With one word – reasonable.
There wouldn't be many people who would benefit much from it. Beginners would need a lot more context and examples, while more experienced developers wouldn't learn much new. Mixing principles with a more specific suggested architecture doesn't help either.
Clean Architecture is useful to start a conversation, provoke questions, or give ideas how to explain patterns one understands on a subconscious level.
There wouldn't be many people who would benefit much from it. Beginners would need a lot more context and examples, while more experienced developers wouldn't learn much new. Mixing principles with a more specific suggested architecture doesn't help either.
Clean Architecture is useful to start a conversation, provoke questions, or give ideas how to explain patterns one understands on a subconscious level.
Read
November 28, 2019This book was exactly what I expected it to be.
April 14, 2021
Լավն էր շատ, բայց մի 2 տարի հետո 2րդ փորձ կլինի կարդալու, լիքը բաներ կային որի գիտելիքները չունեի ու լրիվ չէի հասկանում, չնայած էն մտքերը տվեց որ սրանից հետո ինչ-որ պռոյեկտների մոտիկանալուց ուրիշ աչքով կնայեմ։
August 1, 2021
This book indeed has a lot of golden nuggets in terms of SOLID principles and their application into the whole of clean architecture, however, just as a personal opinion, as it is with all of Uncle Bob's work, it comes with a lot of unnecessary build-up(and very little of PRACTICAL code samples). I do understand that this is an architecture book and apparently the UML diagrams are supposed to be enough but it would have been nice to provide at least one good concrete Bad to Good architecture kind of sample. The content/theory itself is simply gold and provides and much needed insight into the WHY of clean code paradigm, which I enjoyed a lot.
October 15, 2018
this is really an excelent book about creating good, reusable and disconnected from infrastructure details code.
If clean code was all about the code, this is about how you structure the code to make it more reusable, framewoderk independent and solid.
If you think MVC and Rails or Django or Phoenix is the way to go for a web project, think again with this book.
Great software does not rely on any framework. It just uses the framework when it needs.
If clean code was all about the code, this is about how you structure the code to make it more reusable, framewoderk independent and solid.
If you think MVC and Rails or Django or Phoenix is the way to go for a web project, think again with this book.
Great software does not rely on any framework. It just uses the framework when it needs.
July 21, 2024
Якісне продовження "чистої" серії. Друга частина значно цікавіша за попередню, з ще більшою кількістю прикладів. Якщо "Clean Code: A Handbook of Agile Software Craftsmanship" - це основи, або IT-буквар як я говорив у відгуку, то "Clean Architecture" - це вже старша школа.
Автор грунтовно підказує як дизайнити код, який буде задовільяти не лише поточні вимоги, а і буде готовим до нових. Як каже Роберт Мартін, “Ціль архітектури - зменшити затрати на розширення”. Починається книга здалеку - з огляду парадигм програмування типу ООП, функціонального, структурного, тощо. Доповнюється вже більш приземленими поняттями і принципами. До речі, саме після прочитання цієї книги я зрозумів, що Single Responsibility насправді має на увазі не одну задачу яка рішається компонентом, а саме одну причину бути зміненим. Однією з найцінніших порад з книги я можу назвати “Відкладіть прийняття рішення, наскільки це можливо”, особливо коли це стосується технічних питань. Цього можна зокрема досягти використовуючи домен-центричні архітектури типу Hexagonal (Get Your Hands Dirty on Clean Architecture: A hands-on guide to creating clean web applications with code examples in Java) або Clean. Важливо пам’ятати що низькорівневі деталі мають залежати від високорівневих, як плагіни залежать від головного модуля, а не навпаки. Іншими словами це можна сказати що архітектура має бути use-case-driven, а не framework-driven. В кінці книги автор вводить термін "кричаща архітектура", описуючи добре спроектований проект, проект суть якого можна зрозуміти швидко оглянувши назви модулів і класів.
Це точно одна з книг, до якої ви будете повертатися знову і знову, доповнюючи її новим досвідом і реальностями індустрії. Варто мати її в своїй бібліотеці. Рекомендую
Автор грунтовно підказує як дизайнити код, який буде задовільяти не лише поточні вимоги, а і буде готовим до нових. Як каже Роберт Мартін, “Ціль архітектури - зменшити затрати на розширення”. Починається книга здалеку - з огляду парадигм програмування типу ООП, функціонального, структурного, тощо. Доповнюється вже більш приземленими поняттями і принципами. До речі, саме після прочитання цієї книги я зрозумів, що Single Responsibility насправді має на увазі не одну задачу яка рішається компонентом, а саме одну причину бути зміненим. Однією з найцінніших порад з книги я можу назвати “Відкладіть прийняття рішення, наскільки це можливо”, особливо коли це стосується технічних питань. Цього можна зокрема досягти використовуючи домен-центричні архітектури типу Hexagonal (Get Your Hands Dirty on Clean Architecture: A hands-on guide to creating clean web applications with code examples in Java) або Clean. Важливо пам’ятати що низькорівневі деталі мають залежати від високорівневих, як плагіни залежать від головного модуля, а не навпаки. Іншими словами це можна сказати що архітектура має бути use-case-driven, а не framework-driven. В кінці книги автор вводить термін "кричаща архітектура", описуючи добре спроектований проект, проект суть якого можна зрозуміти швидко оглянувши назви модулів і класів.
Це точно одна з книг, до якої ви будете повертатися знову і знову, доповнюючи її новим досвідом і реальностями індустрії. Варто мати її в своїй бібліотеці. Рекомендую
March 28, 2021
It's a great book on software architecture, but I wished it had more examples and case studies.
August 8, 2021
This was the third book I read from uncle bob, and I think his clean trilogy is a must-read for every developer. The reason lies in what these books give you to think about. While there are hot trends(hot USELESS trends!) about "Which language is the best", "Which framework is the best" to get people to drown in, in his books, you read about discipline, responsibility, training, and professionalism. And that is what we need these days!
In this particular book, we learn about clean architecture, or how to make our software easy to build and maintain. Besides priniciples of clean architecture, the book tries to give a historical background about how the principle was founded, and this approach helps a lot to understand them.
But still this is a hard topic to grasp, and although reading this book improves your coding skills immediately, still There are many vague guidlines, which can only be mastered through training and experience. although I can imagine one takes another path, and may not agree with all the guidlines of the book, still is is a must-read for what it gives you to think about when writing code.
In this particular book, we learn about clean architecture, or how to make our software easy to build and maintain. Besides priniciples of clean architecture, the book tries to give a historical background about how the principle was founded, and this approach helps a lot to understand them.
But still this is a hard topic to grasp, and although reading this book improves your coding skills immediately, still There are many vague guidlines, which can only be mastered through training and experience. although I can imagine one takes another path, and may not agree with all the guidlines of the book, still is is a must-read for what it gives you to think about when writing code.
August 6, 2020
1.5/5
The only useful chapter of this book is the final one by Simon Brown taken from Software Architecture for Developers. The rest of this book is totally useless if you've read Clean Code.
"Clean Architecture" is a very theoretical book, mostly filled with stories from Uncle Bob's past. The SOLID principles are repeated once again, and only a very small part of this abstract book is actually focused on architecture (where the concepts are roughly explained with no practical examples).
At the end of the day, I wouldn't recommend this book to anyone. People already familiar with the concepts won't learn anything new, and I doubt beginners will understand them adequately from this book alone. Unlike Clean Code and Clean Coder, Clean Architecture is a waste of time. There's no real substance and I struggled to read it through to the end.
The only useful chapter of this book is the final one by Simon Brown taken from Software Architecture for Developers. The rest of this book is totally useless if you've read Clean Code.
"Clean Architecture" is a very theoretical book, mostly filled with stories from Uncle Bob's past. The SOLID principles are repeated once again, and only a very small part of this abstract book is actually focused on architecture (where the concepts are roughly explained with no practical examples).
At the end of the day, I wouldn't recommend this book to anyone. People already familiar with the concepts won't learn anything new, and I doubt beginners will understand them adequately from this book alone. Unlike Clean Code and Clean Coder, Clean Architecture is a waste of time. There's no real substance and I struggled to read it through to the end.
April 3, 2020
What an incredible book. I felt like my spirit was rising.
I certainly learnt a lot in this book, than I could have by redoing the same mistakes over the years.
It's definitely a must-read book.
Some of my favorite quotes:
I certainly learnt a lot in this book, than I could have by redoing the same mistakes over the years.
It's definitely a must-read book.
Some of my favorite quotes:
If you think good architecture is expensive, try bad architecture.
The only way to go fast, is to go well.
Software was invented to be “soft.” It was intended to be a way to easily change the behavior of machines. If we’d wanted the behavior of machines to be hard to change, we would have called it hardware.
The architecture of a system is defined by boundaries that separate high-level policy from low-level detail and follow the Dependency Rule.
The first rule of software design—whether for testability or for any other reason—is always the same: Don’t depend on volatile things.
July 1, 2020
Mixed feelings about this book. On one side, it explains what software architecture is about, filled with valuable design principles (at class level and at component level).
On the other side, it's a very short book, basically with a fast compilation of everything he said before. Even when he touches fresh subjects, like distributed systems (SOA/Microservices), the chapters are a little bit shallow. I've missed more code samples to clarify some concepts.
Don't get me wrong: it's a very good book, but read it as something like "the foundation of software architecture" (read the table of contents before so that you do not get disappointed).
ps.: I'd like to see Uncle Bob writing about other - and more specific - things, such as DDD, CQRS, Event Sourcing, some cloud services and patterns, etc.
On the other side, it's a very short book, basically with a fast compilation of everything he said before. Even when he touches fresh subjects, like distributed systems (SOA/Microservices), the chapters are a little bit shallow. I've missed more code samples to clarify some concepts.
Don't get me wrong: it's a very good book, but read it as something like "the foundation of software architecture" (read the table of contents before so that you do not get disappointed).
ps.: I'd like to see Uncle Bob writing about other - and more specific - things, such as DDD, CQRS, Event Sourcing, some cloud services and patterns, etc.
January 28, 2018
Clean Guide for an Architect
The book covers different sides of the Software Architect role. The conflicting collaboration of business and technology. The crucial architect's focus topics. The architecture principles derived from the famous SOLID principles and proven by decades. Some of the common architecture mistakes.
All topics of the book have bright and laconic descriptions. The are also many colorful and didactic examples to the ideas, often taken from the author's experience. And besides, there is a whole appendix chapter full of autobiographical stories.
I find this book great at presenting the essence of the Architect role and the core principles one should follow.
The book covers different sides of the Software Architect role. The conflicting collaboration of business and technology. The crucial architect's focus topics. The architecture principles derived from the famous SOLID principles and proven by decades. Some of the common architecture mistakes.
All topics of the book have bright and laconic descriptions. The are also many colorful and didactic examples to the ideas, often taken from the author's experience. And besides, there is a whole appendix chapter full of autobiographical stories.
I find this book great at presenting the essence of the Architect role and the core principles one should follow.
January 21, 2019
Is a great book, I demystified some thoughts I had about software architecture
- Be aware of how to architect your unit test.
- How to apply SOLID principles in a web service architecture
- A monolithic architect is not bad if you know the advantage and disadvantage
- Use framework but not married your business logic to them
- Be aware of how to architect your unit test.
- How to apply SOLID principles in a web service architecture
- A monolithic architect is not bad if you know the advantage and disadvantage
- Use framework but not married your business logic to them
January 21, 2024
Întreaga carte explorează diverse fațete ale principiului inversării dependențelor: modulele de nivel înalt nu trebuie să depindă de modulele de nivel scăzut, ci ambele trebuie să depindă de abstracții. Dacă acest principiu este respectat, atunci arhitectura este una curată și permite adăugarea de noi componente fără a afecta modulele existente. Componentele de nivel scăzut ar trebui să se comporte ca niște plugin-uri pentru componentele de nivel înalt.
Cartea mi s-a părut în mare măsură repetitivă, iar din cauza naturii mult mai abstracte a arhitecturii, a principiilor sale și a apelor tulburi în care acestea înoată, atitudinea lui Uncle Bob, de tiran care deține tabletele cu porunci, s-a diminuat puțin.
Cu toate că nu a avut un impact atât de puternic asupra mea precum ”Clean Code”, m-a făcut să fiu mai conștientă și mai atentă asupra dependențelor pe care le introduc în codul de fiecare zi. Din anexă am aflat și motivul pentru care autorul se auto-numește ”Uncle Bob”, ceea ce a fost o descoperire amuzantă.
Cartea mi s-a părut în mare măsură repetitivă, iar din cauza naturii mult mai abstracte a arhitecturii, a principiilor sale și a apelor tulburi în care acestea înoată, atitudinea lui Uncle Bob, de tiran care deține tabletele cu porunci, s-a diminuat puțin.
Cu toate că nu a avut un impact atât de puternic asupra mea precum ”Clean Code”, m-a făcut să fiu mai conștientă și mai atentă asupra dependențelor pe care le introduc în codul de fiecare zi. Din anexă am aflat și motivul pentru care autorul se auto-numește ”Uncle Bob”, ceea ce a fost o descoperire amuzantă.
February 3, 2020
A very useful reference book that I will definitely come back to often. It makes me understand a lot more about why some architecture is good or bad.
September 17, 2023
This is a technical read that is akin to a Bible for Software Developers. This was my second time reading it, it's worth it's wait in gold.
June 19, 2021
Regardless of whether the architecture suggested by Robert C. Martin (which is so similar to the hexagonal architecture) and regardless of he is right with his principles or not, I think that's worth mentioning that the book is well written and provides content that I think it worths thinking about. I recommend the book and as any other book on principles, patterns, architecture, good practices, this also has to be read with a critical mindset.
April 2, 2020
Hooboy, what to say... Let me start by pointing out that the concepts and ideas that this book presents to the reader are pretty sound (... or should I say - SOLID?) and the writing style is what you'd expect from Uncle Bob: the words just flow, the language is simple, natural and clear and the wit sharp - all of it making the reading process a pleasurable affair. And the book is full of his sheer love for the profession and his geekiness and the trips down the memory lane of a battle-tested veteran who fought in the trenches of the early day computer booms and took part in shaping the best things of our present-day profession.
However, the way this book was envisioned has left me deeply dissatisfied and with a lingering feeling that it should never have been a book at all... Frankly, the more I think about it, the more I feel that a 30-40 page whitepaper would have been a far better format for the contents found within. My reasoning to be found below.
The initial 20-25% of the book is almost pure waffle and essentially just summarizes and grossly simplifies principles from Bob's other works and works of other renown programming professionals. It's all sound advice but my issue with presenting it here in this manner is that I can't imagine it being very useful or practical to readers that are unfamiliar with the concepts and it's frankly useless to readers that are familiar.
The next 20-25% is in part application of previously named principles and concepts on higher-level design and in part a list of prerequisites, dos and don'ts that a proper software architecture must satisfy - in essence a very slow intro into the clean architecture.
Finally, at page 200 the plot thickens, clean architecture is presented and it's a shocker! It's simple, effective and familiar - mostly because it's basically a specialized version of DDDLite employing a hexagonal/ports&adapters architecture. The architecture is elaborated on maybe 20 pages in total and then the remaining 150+ is a series of anecdotes and a whole lot of repetition of what's been said previously but phrased a bit differently and in slightly altered context. Yes, yes, repetitio est mater studiorum, someone's taken that quite literally.
Not uncommon occurrence are 90s teleshop-style bad practice examples, you know the type - picture a guy struggling to use a wrench in an obviously artificial and fake way, only to be presented with a solution to his problems. Some the examples used to illustrate the problems with traditional/mainstream architectures feels artificially exaggerated and blown out of proportion. A less extreme but a more lifelike example always wins. Additionally, Bob hasn't been doing much testing of, nor has he apparently worked with ORMs - in most ecosystems GUI testing is far from the bogeyman it once was and I can't remember if ORMs (at least the most popular Java ones) ever required you to break encapsulation and expose your object's innards to the world.
Also, were you expecting elaborate examples that go from high component level down to the classes? A real-world example complex enough to show all the intricacies and dilemmas you as a developer and an architect would be exposed to when adopting clean architecture yet simple enough to fit inside a book? Puny mortal, those are not for you! You can have examples marginally more complex than hello world apps accompanied by programming history lessons (which were fun but hardly educational).
To sum it all up - it's a pleasant read but the parts I enjoyed the most had nothing to do with software architecture and everything to do with who Uncle Bob is as a person, author and a software professional. If you want great and meaningful material on software architecture that advocates for more or less the same principles as The Clean Architecture, go read DDD by Eric Evans and then Implementing DDD by Vernon Vaughn - you'll be up for a 1000-page ride that actually teaches you something of practical value.
However, the way this book was envisioned has left me deeply dissatisfied and with a lingering feeling that it should never have been a book at all... Frankly, the more I think about it, the more I feel that a 30-40 page whitepaper would have been a far better format for the contents found within. My reasoning to be found below.
The initial 20-25% of the book is almost pure waffle and essentially just summarizes and grossly simplifies principles from Bob's other works and works of other renown programming professionals. It's all sound advice but my issue with presenting it here in this manner is that I can't imagine it being very useful or practical to readers that are unfamiliar with the concepts and it's frankly useless to readers that are familiar.
The next 20-25% is in part application of previously named principles and concepts on higher-level design and in part a list of prerequisites, dos and don'ts that a proper software architecture must satisfy - in essence a very slow intro into the clean architecture.
Finally, at page 200 the plot thickens, clean architecture is presented and it's a shocker! It's simple, effective and familiar - mostly because it's basically a specialized version of DDDLite employing a hexagonal/ports&adapters architecture. The architecture is elaborated on maybe 20 pages in total and then the remaining 150+ is a series of anecdotes and a whole lot of repetition of what's been said previously but phrased a bit differently and in slightly altered context. Yes, yes, repetitio est mater studiorum, someone's taken that quite literally.
Not uncommon occurrence are 90s teleshop-style bad practice examples, you know the type - picture a guy struggling to use a wrench in an obviously artificial and fake way, only to be presented with a solution to his problems. Some the examples used to illustrate the problems with traditional/mainstream architectures feels artificially exaggerated and blown out of proportion. A less extreme but a more lifelike example always wins. Additionally, Bob hasn't been doing much testing of, nor has he apparently worked with ORMs - in most ecosystems GUI testing is far from the bogeyman it once was and I can't remember if ORMs (at least the most popular Java ones) ever required you to break encapsulation and expose your object's innards to the world.
Also, were you expecting elaborate examples that go from high component level down to the classes? A real-world example complex enough to show all the intricacies and dilemmas you as a developer and an architect would be exposed to when adopting clean architecture yet simple enough to fit inside a book? Puny mortal, those are not for you! You can have examples marginally more complex than hello world apps accompanied by programming history lessons (which were fun but hardly educational).
To sum it all up - it's a pleasant read but the parts I enjoyed the most had nothing to do with software architecture and everything to do with who Uncle Bob is as a person, author and a software professional. If you want great and meaningful material on software architecture that advocates for more or less the same principles as The Clean Architecture, go read DDD by Eric Evans and then Implementing DDD by Vernon Vaughn - you'll be up for a 1000-page ride that actually teaches you something of practical value.
November 13, 2019
If you read Clean Code: A Handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers, you may expect something similar to those two books about architecture. However, this book here lacks the practical, hands-on advice you get with the other two books. Clean Architecture talks a lot about SOLID and decoupling. Part 5 (Architecture), on the other hand, is a rather muddled collection of shallow concepts that lack the necessary details to be helpful. Great, there is a box and an arrow and a red line – but what does that mean? How do you make those boundaries? What should you consider? This book lacks all those basic parts that every other book on architecture offers - and not in a good way where you replace the parts that everyone knows with new and unique content. This book lets you guess what those images should mean and offers no help to apply those techniques with your own code.
To prove the importance of good software design we find a case study in chapter 1. If you only skim over, then everything looks sound and supportive of the claims made by Martin. However, as soon as you look a little bit closer, the whole study falls apart. There are 6 graphs to illustrate the findings of a study. Only 2 graphs bother with labelling both axes. If you look even closer, only 5 graphs are about that “study” and they tell a rather different story than what Martin makes out of it. The last graph is the best. It is about a small experiment solving the Roman Numerals Kata and measuring the time it took Jason Groman to complete it (3x with TDD, 3x without TDD). This graph cuts off 75% of the values (by starting at 22 minutes instead of 0), what turns the difference in speed from 10% to something that looks like a 50% time saving. Using tricks like this one to prove that TDD is such a great time saver is a disappointment, especially since Martin is such a vocal proponent for TDD. Is that all he has to prove his approach?
For me this book is an absolute disappointment and the worst one on architecture I ever read.
To prove the importance of good software design we find a case study in chapter 1. If you only skim over, then everything looks sound and supportive of the claims made by Martin. However, as soon as you look a little bit closer, the whole study falls apart. There are 6 graphs to illustrate the findings of a study. Only 2 graphs bother with labelling both axes. If you look even closer, only 5 graphs are about that “study” and they tell a rather different story than what Martin makes out of it. The last graph is the best. It is about a small experiment solving the Roman Numerals Kata and measuring the time it took Jason Groman to complete it (3x with TDD, 3x without TDD). This graph cuts off 75% of the values (by starting at 22 minutes instead of 0), what turns the difference in speed from 10% to something that looks like a 50% time saving. Using tricks like this one to prove that TDD is such a great time saver is a disappointment, especially since Martin is such a vocal proponent for TDD. Is that all he has to prove his approach?
Another great example of the problems with this book is chapter 30 (the database is a detail). He throws in a bold claim and spend the next paragraph to explain that this can be misinterpreted and that he only talks about the technology and not the data model. Instead of explaining that, he could have written what he meant in the first paragraph. The rest of this chapter is a rather generic and short explanation on why one needs databases in the first place. Nothing new, nothing helpful in any form from an architectural perspective and again so shallow that you can’t learn anything from it.
For me this book is an absolute disappointment and the worst one on architecture I ever read.
Displaying 1 - 30 of 494 reviews