Clean Architecture by Robert C. Martin

Clean Architecture Reviews

• 
  Rod Hilton

  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.
• 
  Eduards Sizovs

  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".
• 
  Tim

  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.
• 
  Sebastian Gebski

  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.
• 
  Sina

  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.
• 
  Mohamed Elsherif

  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.
• 
  Paul Sochiera

  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.
• 
  Paul Newman

  This book was exactly what I expected it to be.
• 
  Mher Khachatryan

  Լավն էր շատ, բայց մի 2 տարի հետո 2րդ փորձ կլինի կարդալու, լիքը բաներ կային որի գիտելիքները չունեի ու լրիվ չէի հասկանում, չնայած էն մտքերը տվեց որ սրանից հետո ինչ-որ պռոյեկտների մոտիկանալուց ուրիշ աչքով կնայեմ։
• 
  Petar Ivanov

  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.
• 
  Maris Krivtezs

  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.
• 
  Thiago Ramos

  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.
• 
  Nikolay

  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.
• 
  Tomasz

  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.
• 
  Nariman

  It's a great book on software architecture, but I wished it had more examples and case studies.
• 
  Shayan aminnjad

  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.
• 
  Meysam

  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:
  
  

  
  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.
  
• 
  Robson Castilho

  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.
• 
  Pavel Gatilov

  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.
• 
  Madhur Bhargava

  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.
• 
  Mengyi

  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.
• 
  Adolfo

  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.
• 
  Alan Tavares

  Muito recomendado para estrutura de aplicações.
  Ótima leitura e grande conhecimento compartilhado pelo Robert Martin.
  Não vou dar spoilers mas vale muito a leitura para área de desenvolvimento assim como os demais livros similares como clean code e clean coders.
• 
  Giovani Facchini

  Bob describes his concept of software architecture and explain best practices and concepts used in order to achieve ease of change (evolution).
  
  Before I have started to read this book, I thought it would focus on a top-down approach of how to design systems. Therefore, I was expecting to see a lot of database types / strategy, deployment best practices, load balancers, microservices, etc. My expectations could not have been more wrong. :)
  
  The greatness of this book lies on showing the author's view architecture (properties that allow software to change and evolve), the history of programming paradigms and how they take away features to improve safety, the SOLID principles (SRP, OCP, LSP, ISP, DIP), the trade-off between component cohesion concepts (REP, CCP and CRP), and a lot of other things focused on making change easier.
  
  I understand and realize that many controversial topics are covered and so there is some anymosity around about this book. For me, it was great because it will help me to understand better how certain decisions in projects were made and get less frustrated with legacy systems.
  
  There are a lot of concepts in the book, so you better take notes while reading the parts and concepts you believe will be useful to you.
• 
  Martin Nachev

  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.
• 
  Wojtek Erbetowski

  This book was exactly what I expected it to be.
  
  I have attended several talks by Uncle Bob and read his 'Clean Code' a long time ago. I wasn't surprised by the contents, as his stand on the architecture (as it seems to me) is consistent and stable. Some of his war stories are hard to overvalue.
  
  The most important part I have read there is about SRP and how to understand it differently than it's commonly understood.
  
  I recommend the book to most software engineers, to both learn, and get a topic to discuss during tech events.